Partager via

Comment l'environnement d'exécution localise les assemblages

Remarque

Cet article est spécifique à .NET Framework. Elle ne s’applique pas aux implémentations plus récentes de .NET, notamment .NET 6 et versions ultérieures.

Pour déployer correctement votre application .NET Framework, vous devez comprendre comment le Common Language Runtime localise et lie les assemblys qui composent votre application. Par défaut, le runtime tente de lier avec la version exacte d’un assembly avec lequel l’application a été générée. Ce comportement par défaut peut être remplacé par les paramètres du fichier de configuration.

Le Common Language Runtime effectue plusieurs étapes lors de la tentative de localisation d’un assembly et de résolution d’une référence d’assembly. Chaque étape est expliquée dans les sections suivantes. Le terme de détection est souvent utilisé lors de la description de la façon dont le runtime localise les assemblys ; elle fait référence à l’ensemble d’heuristiques utilisées pour localiser l’assembly en fonction de son nom et de sa culture.

Remarque

Vous pouvez afficher les informations de liaison dans le fichier journal à l’aide de la visionneuse du journal de liaison d’assembly (Fuslogvw.exe), qui est incluse dans le Kit de développement logiciel (SDK) Windows.

Initiation de la liaison

Le processus de localisation et de liaison à un assembly commence lorsque le runtime tente de résoudre une référence à un autre assembly. Cette référence peut être statique ou dynamique. Le compilateur enregistre les références statiques dans les métadonnées du manifeste d'assemblage au moment de la compilation. Les références dynamiques sont construites à la volée suite à l’appel de différentes méthodes, telles que Assembly.Load.

La méthode recommandée pour référencer un assembly consiste à utiliser une référence complète, notamment le nom de l’assembly, la version, la culture et le jeton de clé publique (le cas échéant). Le runtime utilise ces informations pour localiser l’assembly, en suivant les étapes décrites plus loin dans cette section. Le runtime utilise le même processus de résolution, que la référence soit utilisée pour un assembly statique ou dynamique.

Vous pouvez également faire une référence dynamique à un assembly en fournissant la méthode appelante avec uniquement des informations partielles sur l’assembly, telles que la spécification du nom de l’assembly uniquement. Dans ce cas, l'assembly n'est recherché que dans le répertoire de l'application et aucune autre vérification n'est effectuée. Il est possible de créer une référence partielle à l’aide d’une des méthodes de chargement des assemblys, telle que Assembly.Load ou AppDomain.Load.

Enfin, vous pouvez effectuer une référence dynamique à l’aide d’une méthode telle que Assembly.Load et fournir uniquement des informations partielles. Vous pouvez ensuite qualifier la référence à l’aide de l’élément <qualifierAssembly> dans le fichier de configuration de l’application. Cet élément vous permet de fournir les informations de référence complètes (nom, version, culture et, le cas échéant, le jeton de clé publique) dans votre fichier de configuration d’application au lieu de votre code. Vous utiliseriez cette technique si vous souhaitiez qualifier entièrement une référence à un assembly en dehors du répertoire de l’application, ou si vous vouliez référencer un assembly dans le Global Assembly Cache, mais que vous vouliez spécifier la référence complète dans le fichier de configuration au lieu de votre code.

Remarque

Ce type de référence partielle ne doit pas être utilisé avec des assemblys partagés entre plusieurs applications. Étant donné que les paramètres de configuration sont appliqués par application et non par assembly, un assembly partagé utilisant ce type de référence partielle exigerait que chaque application utilisant l’assembly partagé ait les informations éligibles dans son fichier de configuration.

Le runtime utilise les étapes suivantes pour résoudre une référence d’assembly :

  1. Détermine la version correcte de l’assembly en examinant les fichiers de configuration applicables, notamment le fichier de configuration de l’application, le fichier de stratégie d’éditeur et le fichier de configuration de l’ordinateur. Si le fichier de configuration se trouve sur un ordinateur distant, le runtime doit d’abord localiser et télécharger le fichier de configuration de l’application.

  2. Il vérifie si le nom de l’assembly a déjà été lié et, si c’est le cas, il utilise l’assembly précédemment chargé. Si une demande précédente de chargement de l’assembly a échoué, la requête a échoué immédiatement sans tenter de charger l’assembly.

    Remarque

    La mise en cache des échecs de liaison d’assembly est nouvelle dans .NET Framework version 2.0.

  3. Vérifie le global assembly cache. S'il y trouve l'assembly, il l'utilise.

  4. Sondes pour l'assemblage en procédant comme suit :

    1. Si la configuration et la politique de l'éditeur n'affectent pas la référence d'origine et si la demande de liaison a été créée en utilisant la méthode Assembly.LoadFrom, l'environnement d'exécution vérifie les indications d'emplacement.

    2. Si un codebase se trouve dans les fichiers de configuration, le runtime vérifie uniquement cet emplacement. Si cette sonde échoue, le runtime détermine que la demande de liaison a échoué et qu’aucune autre détection ne se produit.

    3. Sondes pour l’assemblage à l’aide des heuristiques décrites dans la section de sondage. Si l’assembly est introuvable après la détection, le runtime demande à Windows Installer de fournir l’assembly. Il s’agit d’une fonctionnalité d’installation à la demande.

      Remarque

      Il n'existe aucune vérification de version pour les assemblages sans noms forts, et le moteur d'exécution ne vérifie pas non plus le cache global d'assemblage pour les assemblages sans noms forts.

Étape 1 : Examen des fichiers de configuration

Le comportement de liaison d’assembly peut être configuré à différents niveaux en fonction de trois fichiers XML :

  • Fichier de configuration de l’application.

  • Fichier de stratégie de l’éditeur.

  • Fichier de configuration de l’ordinateur.

Ces fichiers suivent la même syntaxe et fournissent des informations telles que les redirections de liaison, l’emplacement du code et les modes de liaison pour des assemblys particuliers. Chaque fichier de configuration peut contenir un <assemblyBinding> élément qui redirige le processus de liaison. Les éléments enfants de l’élément<assemblyBinding> incluent l’élément<dependentAssembly>. Les enfants de l’élément<dependentAssembly> incluent l’élément<assemblyIdentity>, l’élément<bindingRedirect> et l’élément<codeBase>.

Remarque

Les informations de configuration sont disponibles dans les trois fichiers de configuration ; tous les éléments ne sont pas valides dans tous les fichiers de configuration. Par exemple, le mode de liaison et les informations de chemin privé peuvent uniquement se trouver dans le fichier de configuration de l’application. Pour obtenir la liste complète des informations contenues dans chaque fichier, consultez Configuration des applications à l’aide de fichiers de configuration.

Fichier de configuration de l'application

Tout d’abord, le Common Language Runtime vérifie le fichier de configuration de l’application pour obtenir des informations qui remplacent les informations de version stockées dans le manifeste de l’assembly appelant. Le fichier de configuration de l’application peut être déployé avec une application, mais n’est pas requis pour l’exécution de l’application. En règle générale, la récupération de ce fichier est presque instantanée, mais dans les situations où la base d’applications se trouve sur un ordinateur distant, comme dans un scénario web, le fichier de configuration doit être téléchargé.

Pour les exécutables clients, le fichier de configuration de l’application réside dans le même répertoire que l’exécutable de l’application et a le même nom de base que l’exécutable avec une extension .config. Par exemple, le fichier de configuration de C:\Program Files\Myapp\Myapp.exe est C:\Program Files\Myapp\Myapp.exe.config. Dans un scénario basé sur un navigateur, le fichier HTML doit utiliser l’élément <link> pour pointer explicitement vers le fichier de configuration.

Le code suivant fournit un exemple simple de fichier de configuration d’application. Cet exemple ajoute un TextWriterTraceListener à la collection Listeners pour activer l'enregistrement des informations de débogage dans un fichier.

<configuration>
   <system.diagnostics>
      <trace useGlobalLock="false" autoflush="true" indentsize="0">
         <listeners>
            <add name="myListener" type="System.Diagnostics.TextWriterTraceListener, system version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="c:\myListener.log" />
         </listeners>
      </trace>
   </system.diagnostics>
</configuration>

Fichier de stratégie de l’éditeur

Deuxièmement, le runtime examine le fichier de stratégie de l’éditeur, s’il en existe un. Les fichiers de stratégie de l'éditeur sont distribués par un éditeur de composant en tant que correctif ou mise à jour d'un composant partagé. Ces fichiers contiennent des informations de compatibilité émises par l’éditeur du composant partagé qui dirige une référence d’assembly vers une nouvelle version. Contrairement aux fichiers de configuration de l’application et de l’ordinateur, les fichiers de stratégie d’éditeur sont contenus dans leur propre assembly qui doit être installé dans le Global Assembly Cache.

Voici un exemple de fichier de configuration de stratégie de publication :

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

            <dependentAssembly>
                <assemblyIdentity name="asm6" publicKeyToken="c0305c36380ba429" />
                <bindingRedirect oldVersion="3.0.0.0" newVersion="2.0.0.0"/>
            </dependentAssembly>

        </assemblyBinding>
    </runtime>
</configuration>

Pour créer un assembly, vous pouvez utiliser l’outil Al.exe (Assembly Linker) avec une commande telle que :

Al.exe /link:asm6.exe.config /out:policy.3.0.asm6.dll /keyfile: compatkey.dat /v:3.0.0.0

compatkey.dat est un fichier de clé de nom fort. Cette commande crée un assembly de nom fort que vous pouvez placer dans le Global Assembly Cache.

Remarque

La politique de l'éditeur affecte toutes les applications qui utilisent un composant partagé.

Le fichier de configuration de stratégie d’éditeur remplace les informations de version provenant de l’application (c’est-à-dire du manifeste d’assembly ou du fichier de configuration de l’application). S’il n’existe aucune instruction dans le fichier de configuration de l’application pour rediriger la version spécifiée dans le manifeste d’assembly, le fichier de stratégie d’éditeur remplace la version spécifiée dans le manifeste d’assembly. Toutefois, s’il existe une instruction de redirection dans le fichier de configuration de l’application, la stratégie d’éditeur remplace cette version plutôt que celle spécifiée dans le manifeste.

Un fichier de stratégie d’éditeur est utilisé lorsqu’un composant partagé est mis à jour et que la nouvelle version du composant partagé doit être récupérée par toutes les applications utilisant ce composant. Les paramètres du fichier de politique de l’éditeur l'emportent sur ceux du fichier de configuration de l’application, sauf si celui-ci applique le mode sécurisé.

Mode sans échec

Les fichiers de stratégie de publication sont généralement installés explicitement dans le cadre d'un service pack ou d'une mise à jour de programme. En cas de problème avec le composant partagé mis à jour, vous pouvez ignorer les substitutions spécifiées dans le fichier de stratégie d'éditeur en utilisant le mode sans échec. Le mode sécurisé est déterminé par l’élément <publisherPolicy apply="yes|no"/>, situé uniquement dans le fichier de configuration de l'application. Il spécifie si les informations de configuration du fichier de stratégie d'éditeur doivent être supprimées du processus de liaison.

Le mode sans échec peut être défini pour toute l'application ou pour des assemblys spécifiques. Autrement dit, vous pouvez désactiver la stratégie pour toutes les assemblées qui composent l'application, ou l'activer pour certaines tout en la désactivant pour d'autres. Pour appliquer de manière sélective la stratégie d’éditeur aux assemblys qui composent une application, définissez <publisherPolicy apply=no/> et spécifiez les assemblys que vous souhaitez affecter à l’aide de l’élément <dépendantAssembly> . Pour appliquer la stratégie d’éditeur à tous les assemblages qui composent l’application, paramétrez< "publisherPolicy apply=no"/> sans aucun élément d'assemblages dépendants. Pour plus d’informations sur la configuration, consultez Configuration des applications à l’aide de Fichiers de configuration.

Fichier de configuration de l’ordinateur

Troisièmement, le runtime examine le fichier de configuration de l’ordinateur. Ce fichier, appelé Machine.config, réside sur l’ordinateur local dans le sous-répertoire Config du répertoire racine où le runtime est installé. Ce fichier peut être utilisé par les administrateurs pour spécifier des restrictions de liaison d’assembly locales à cet ordinateur. Les paramètres du fichier de configuration de l’ordinateur sont prioritaires sur tous les autres paramètres de configuration ; Toutefois, cela ne signifie pas que tous les paramètres de configuration doivent être placés dans ce fichier. La version déterminée par le fichier de stratégie d’administrateur est finale et ne peut pas être remplacée. Les remplacements spécifiés dans le fichier Machine.config affectent toutes les applications. Pour plus d’informations sur les fichiers de configuration, consultez Configuration des applications à l’aide de Fichiers de configuration.

Étape 2 : Vérification des assemblages précédemment référencés

Si l’assembly demandé a également été demandé dans les appels précédents, le Common Language Runtime utilise l’assembly déjà chargé. Cela peut avoir des conséquences lors de l’affectation d’un nom à des assemblys qui composent une application. Pour plus d’informations sur la dénomination des assemblages, consultez Noms d’assemblages.

Si une demande précédente pour l'assemblage a échoué, les requêtes suivantes échouent immédiatement sans tenter de charger l'assemblage. À compter de .NET Framework version 2.0, les échecs de liaison d’assembly sont mis en cache et les informations mises en cache sont utilisées pour déterminer s’il faut tenter de charger l’assembly.

Remarque

Pour revenir au comportement des versions 1.0 et 1.1 du .NET Framework, qui n’ont pas mis en cache les échecs de liaison, incluez l’élément<disableCachingBindingFailures> dans votre fichier de configuration.

Étape 3 : Vérification du Global Assembly Cache

Pour les assemblys avec un nom fort, le processus de liaison examine ensuite le Global Assembly Cache. Le Global Assembly Cache stocke les assemblys qui peuvent être utilisés par plusieurs applications sur un ordinateur. Tous les assemblages dans le Cache d'Assemblages Global doivent posséder des noms forts.

Étape 4 : Localisation de l’assembly par le biais de Codebases ou de détection

Une fois que la version correcte de l’assembly a été déterminée en utilisant les informations de 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 assemblies à nom fort), le runtime de langage commun tente de trouver l’assembly. Le processus de localisation d’un assembly implique les étapes suivantes :

  1. Si un <élément codeBase> se trouve 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'est effectuée. Si l'assemblage est introuvable, la demande de liaison échoue.

  2. Le runtime sonde ensuite l’assembly référencé à l’aide des règles spécifiées plus loin dans cette section.

Remarque

Si vous avez plusieurs versions d’un assembly dans un répertoire et que vous souhaitez référencer une version particulière de cet assembly, vous devez utiliser l’élément <codeBase> au lieu de l’attribut privatePath de l’élément <de détection> . Si vous utilisez l’élément <de détection> , le runtime cesse de sonder la première fois qu’il trouve un assembly qui correspond au nom d’assembly simple référencé, qu’il s’agisse d’une correspondance correcte ou non. S'il s'agit d'une correspondance correcte, cet assemblage est utilisé. Si elle ne l'est pas, la détection s'interrompt et la liaison échoue.

Localisation de l’assembly via Codebases

Les informations codebase peuvent être fournies à l’aide d’un <élément codeBase> dans un fichier de configuration. Cette base de code est toujours vérifiée avant que le runtime tente de sonder l’assembly référencé. Si un fichier de stratégie d’éditeur contenant la redirection de version finale contient également un élément <codeBase>, cet élément <codeBase> est celui utilisé. Par exemple, si votre fichier de configuration d’application spécifie un <élément codeBase> et un fichier de stratégie d’éditeur qui remplace les informations d’application spécifie également un <élément codeBase> , l’élément <codeBase> dans le fichier de stratégie de l’éditeur est utilisé.

Si aucune correspondance n’est trouvée à l’emplacement spécifié par l’élément <codeBase> , la demande de liaison échoue et aucune autre procédure n’est effectuée. Si le runtime détermine qu’un assembly correspond aux critères 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 à la référence de l’assembly appelant.

Remarque

Les assemblys référencés en dehors du répertoire racine de l’application doivent avoir des noms forts et doivent être installés dans le Global Assembly Cache ou spécifiés à l’aide de l’élément <codeBase> .

Localisation de l'assemblage à l'aide du sondage

S’il n’existe aucun <élément codeBase> dans le fichier de configuration de l’application, le runtime sonde l’assembly à l’aide de quatre critères :

  • Base de l’application, qui est l’emplacement racine où l’application est exécutée.

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

  • Nom, qui est le nom de l'assemblage référencé.

  • Attribut privatePath de l’élément <de détection> , 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é à l’aide de la AppDomainSetup.PrivateBinPath propriété d’un domaine d’application. Lorsqu’il est spécifié dans le code managé, le code privatePath managé est interrogé en premier, suivi du chemin 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 à explorer 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 des sous-répertoires portant le nom de l’assembly. Les répertoires sondés sont les suivants :

  • [base d’application] / [nom de l’assembly].dll

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

Si les informations culturelles sont spécifiées pour l’assembly référencé, seuls les répertoires suivants sont explorés :

  • [base d’application] / [culture] / [nom de l’assemblage].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 la culture et des sous-répertoires nommés pour l’assembly référencé, 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 à l’aide de 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 cesse de rechercher la première fois qu’il trouve un assembly qui correspond au nom d’assembly simple référencé, qu’il s’agisse d’une correspondance correcte ou non. S'il s'agit d'une correspondance correcte, cet assemblage est utilisé. Si elle ne l'est pas, la détection s'interrompt et la liaison échoue.

Si la culture est incluse, les répertoires suivants sont explorés :

  • [base d’application] / [binpath] / [culture] / [nom de l’assembly].dll

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

Si les informations culturelles ne sont pas incluses, les répertoires suivants sont explorés :

  • [base d’application] / [binpath] / [nom de l’assembly].dll

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

Exemples de détection

Compte tenu des informations suivantes :

  • Nom de l’assembly référencé : myAssembly

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

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

  • Culture : de

Le runtime sonde les URL suivantes :

  • http://www.code.microsoft.com/de/myAssembly.dll

  • http://www.code.microsoft.com/de/myAssembly/myAssembly.dll

  • http://www.code.microsoft.com/bin/de/myAssembly.dll

  • http://www.code.microsoft.com/bin/de/myAssembly/myAssembly.dll

Plusieurs assemblages portant le même nom

L’exemple suivant montre comment configurer plusieurs assemblys portant le même nom.

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

Autres emplacements sondés

L'emplacement de l'assemblage peut également être déterminé à l'aide du contexte de liaison actuel. Cela se produit le plus souvent lorsque la Assembly.LoadFrom méthode est utilisée et dans les scénarios d’interopérabilité COM. Si un assembly utilise la LoadFrom méthode pour référencer un autre assembly, l’emplacement de l’assembly appelant est considéré comme un indicateur sur l’emplacement où trouver 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 avec sa sémantique de recherche, puis interroge Windows Installer pour fournir l’assembly. Si aucun assembly correspondant à la demande de liaison n'est fourni, une exception est levée. Cette exception est un TypeLoadException dans le code managé si un type a été référencé, ou un FileNotFoundException si une assemblée en cours de chargement n’a pas été trouvée.

Par exemple, si Assembly1 référence Assembly2 et Assembly1 a été téléchargé à partir de http://www.code.microsoft.com/utils, cet emplacement est considéré comme un indicateur sur l’emplacement où trouver Assembly2.dll. Le runtime sonde alors l’assembly dans http://www.code.microsoft.com/utils/Assembly2.dll et http://www.code.microsoft.com/utils/Assembly2/Assembly2.dll. Si Assembly2 est introuvable à l’un de ces emplacements, le runtime interroge Windows Installer.

Voir aussi

  • Last updated on