Étape 4 : localisation de l'assembly par le biais des codes base ou de la détection

Une fois que la bonne version de l'assembly a été déterminée en utilisant les informations dans la référence de l'assembly appelant et dans les fichiers de configuration, et après avoir vérifié le Global Assembly Cache (uniquement pour les assemblys avec nom fort), le Common Language Runtime tente de trouver l'assembly. Le processus de localisation d'un assembly implique les étapes suivantes :

1. Si un élément <codeBase> est trouvé dans le fichier de configuration de l'application, le runtime vérifie l'emplacement spécifié. Si une correspondance est trouvée, cet assembly est utilisé et aucune détection n'intervient. Si l'assembly n'est pas trouvé dans cet emplacement, la demande de liaison échoue.

2. Le runtime tente ensuite de détecter l'assembly référencé en utilisant les règles spécifiées plus loin dans cette section.

Localisation de l'assembly par codes base

Les informations de base de code peuvent être obtenues en utilisant un élément <codeBase> dans un fichier de configuration. Cette base de code est toujours vérifiée avant que le runtime ne tente de détecter l'assembly référencé. Si un fichier de stratégie de l'éditeur contenant la redirection de la version finale contient aussi un élément <codeBase>, ce dernier est utilisé. Par exemple, si votre fichier de configuration de l'application spécifie un élément <codeBase> et qu'un fichier de stratégie de l'éditeur qui substitue les informations de l'application spécifie aussi un élément <codeBase>, l'élément <codeBase> du fichier de stratégie de l'éditeur est utilisé.

Si aucune correspondance n'est trouvée dans l'emplacement spécifié par l'élément <codeBase>, la demande de liaison échoue et aucune étape supplémentaire n'a lieu. Si le runtime détermine qu'un assembly correspond au critère de l'assembly appelant, il utilise cet assembly. Lorsque le fichier spécifié par l'élément <codeBase> donné est chargé, le runtime vérifie que le nom, la version, la culture et la clé publique correspondent bien à la référence de l'assembly appelant.

Localisation de l'assembly par détection

Si aucun élément <codeBase> ne se situe dans le fichier de configuration de l'application, le runtime tente de détecter l'assembly à l'aide de quatre critères :

• La base de l'application, qui est l'emplacement racine où l'application s'exécute.

• La culture, qui est l'attribut de culture de l'assembly étant référencé.

• Le nom, qui est le nom de l'assembly référencé.

• L'attribut privatePath de l'élément <probing>, qui est la liste définie par l'utilisateur des sous-répertoires sous l'emplacement racine. Cet emplacement peut être spécifié dans le fichier de configuration de l'application et dans le code managé en utilisant la propriété AppendPrivatePath pour un domaine d'application. Lorsqu'il est spécifié dans le code managé, le privatePath du code managé est détecté en premier, suivi du chemin d'accès spécifié dans le fichier de configuration de l'application.

Détection de la base de l'application et des répertoires de culture

Le runtime commence toujours la procédure de détection dans la base de l'application, qui peut être une URL ou le répertoire racine de l'application sur un ordinateur. Si l'assembly référencé n'est pas trouvé dans la base de l'application et qu'aucune information de culture n'est fournie, le runtime recherche tout sous-répertoire avec le nom de l'assembly. Les répertoires détectés incluent :

   [base de l'application] / [nom de l'assembly].dll

   [base de l'application] / [nom de l'assembly] / [nom de l'assembly].dll

Si les informations de culture sont spécifiées pour l'assembly référencé, seuls les répertoires suivants sont détectés :

   [base de l'application] / [culture] / [nom de l'assembly].dll

   [base de l'application] / [culture] / [nom de l'assembly] / [nom de l'assembly].dll

Détection avec l'attribut privatePath

En plus des sous-répertoires de culture et des sous-répertoires nommés pour l'assembly référence, le runtime détecte aussi les répertoires spécifiés en utilisant l'attribut privatePath de l'élément <probing>. Les répertoires spécifiés en utilisant l'attribut privatePath doivent être des sous-répertoires du répertoire racine de l'application. Les répertoires détectés varient en fonction de la présence d'informations de culture dans la demande de l'assembly référencé.

Le runtime interrompt la détection lorsqu'il trouve le premier assembly correspondant au nom simple d'assembly référencé, que cette correspondance soit correcte ou non. Si la correspondance est correcte, cet assembly est utilisé. Si elle ne l'est pas, la détection s'interrompt et la liaison échoue.

Si des informations de culture sont incluses, les répertoires suivants sont détectés :

   [base de l'application] / [binpath] / [culture] / [nom de l'assembly].dll

   [base de l'application] / [binpath] / [culture] / [nom de l'assembly] / [nom de l'assembly].dll

Si des informations de culture ne sont pas incluses, les répertoires suivants sont détectés :

   [base de l'application] / [binpath] / [nom de l'assembly].dll

   [base de l'application] / [binpath] / [nom de l'assembly] / [nom de l'assembly].dll

Exemples de détection

En supposant les informations suivantes :

• Nom de l'assembly référencé : monAssembly

• Répertoire racine de l'application : http://www.code.microsoft.comhttp://www.code.microsoft.com

• L'élément <probing> dans le fichier de configuration spécifie : bin

• Culture : de

Le runtime détecte les URL suivantes :

http://www.code.microsoft.com/de/monAssembly.dll

http://www.code.microsoft.com/de/monAssembly/monAssembly.dll

http://www.code.microsoft.com/bin/de/monAssembly.dll

http://www.code.microsoft.com/bin/de/monAssembly/monAssembly.dll

Plusieurs assemblys ayant le même nom

L'exemple suivant indique comment configurer plusieurs assemblys ayant le même nom.

   <dependentAssembly>
      <assemblyIdentity name="Server" publicKeyToken="c0305c36380ba429" /> 
         <codeBase version="1.0.0.0" NavigateUrl="v1/Server.dll"/>
         <codeBase version="2.0.0.0" NavigateUrl="v2/Server.dll"/>
   </dependentAssembly>

Autres emplacements détectés

L'emplacement de l'assembly peut aussi être déterminé en utilisant le contexte de liaison en cours. Cela se produit le plus souvent lorsque la méthode Assembly.LoadFrom est utilisée et dans des scénarios COM Interop. Si un assembly utilise la méthode LoadFrom pour référencer un autre assembly, l'emplacement de l'assembly appelant est considéré comme étant une indication de l'emplacement de l'assembly référencé. Si une correspondance est trouvée, cet assembly est chargé. Si aucune correspondance n'est trouvée, le runtime continue ses sémantiques de recherche puis demande à Windows Installer de fournir l'assembly. Si aucun assembly correspondant à la demande de liaison n'est fourni, une exception est levée. Il s'agit d'une exception TypeLoadException dans le code managé si un type a été référencé ou d'une exception FileNotFoundException si un assembly étant chargé n'a pas été trouvé.

Par exemple, si Assembly1 référence Assembly2 et qu'Assembly1 a été téléchargé à partir de http://www.code.microsoft.com/utils, cet emplacement est considéré comme une indication de l'emplacement de Assembly2.dll. Le runtime tente ensuite de détecter l'assembly dans http://www.code.microsoft.com/utils/Assembly2.dll et http://www.code.microsoft.com/utils/Assembly2/Assembly2.dll. Si Assembly2 n'est pas trouvé dans ces emplacements, le runtime demande à Windows Installer de fournir l'assembly.

Voir aussi

Concepts

Méthode de localisation des assemblys par le runtime
Scénarios de déploiement pour les applications .NET Framework
Étape 1 : examen des fichiers de configuration
Étape 2 : recherche des assemblys précédemment référencés
Étape 3 : vérification du Global Assembly Cache
Références d'assembly partielles