Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Le nom d’un assembly est stocké dans les métadonnées et a un impact significatif sur l’étendue et l’utilisation de l’assembly par une application. Un assembly nommé fort a un nom complet qui inclut le nom, la culture, la clé publique, le numéro de version et, éventuellement, l’architecture du processeur. Utilisez la FullName propriété pour obtenir le nom complet, fréquemment appelé nom complet, pour les assemblys chargés.
Le runtime utilise les informations de nom pour localiser l’assembly et le différencier des autres assemblys portant le même nom. Par exemple, un assembly nommé fort appelé myTypes peut avoir le nom complet suivant :
myTypes, Version=1.0.1234.0, Culture=en-US, PublicKeyToken=b77a5c561934e089c, ProcessorArchitecture=msil
Dans cet exemple, le nom complet indique que l’assembly myTypes a un nom fort avec un jeton de clé publique, a la valeur de culture pour l’anglais des États-Unis et a un numéro de version de 1.0.1234.0. Son architecture de processeur est msil, ce qui signifie qu’elle sera compilée juste-à-temps (JIT) avec du code 32 bits ou du code 64 bits en fonction du système d’exploitation et du processeur.
Conseil / Astuce
Les ProcessorArchitecture informations autorisent les versions spécifiques au processeur des assemblys. Vous pouvez créer des versions d’un assembly dont l’identité diffère uniquement par l’architecture du processeur, par exemple les versions spécifiques au processeur 32 bits et 64 bits. L’architecture du processeur n’est pas nécessaire pour les noms forts. Pour plus d’informations, consultez AssemblyName.ProcessorArchitecture.
Le code qui demande des types dans un assembly doit utiliser un nom d’assembly complet. Il s’agit de la liaison complète. La liaison partielle, qui spécifie uniquement un nom d’assembly, n’est pas autorisée lors du référencement d’assemblys dans .NET Framework.
Toutes les références d’assembly aux assemblys qui composent .NET Framework doivent également contenir le nom complet de l’assembly. Par exemple, une référence à l’assembly System.Data .NET Framework pour la version 1.0 inclut :
System.data, version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
La version correspond au numéro de version de tous les assemblys .NET Framework fournis avec .NET Framework version 1.0. Pour les assemblys .NET Framework, la valeur de culture est toujours neutre et la clé publique est la même que celle indiquée dans l’exemple ci-dessus.
Par exemple, pour ajouter une référence d’assembly dans un fichier de configuration pour configurer un écouteur de trace, vous devez inclure le nom complet de l’assembly .NET Framework système :
<add name="myListener" type="System.Diagnostics.TextWriterTraceListener, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="c:\myListener.log" />
Remarque
Le runtime traite les noms d’assembly comme non sensibles à la casse lors de la liaison à un assembly, mais conserve tout cas utilisé dans un nom d’assembly. Plusieurs outils du Kit de développement logiciel (SDK) Windows gèrent les noms d’assemblys comme respectant la casse. Pour obtenir des résultats optimaux, gérez les noms d’assembly comme s’ils respectaient la casse.
Nommer les composants d’application
Le runtime ne prend pas en compte le nom de fichier lors de la détermination de l’identité d’un assembly. L’identité d’assembly, qui se compose du nom de l’assembly, de la version, de la culture et du nom fort, doit être claire pour le runtime.
Par exemple, si vous avez un assembly appelé myAssembly.exe qui fait référence à un assembly appelé myAssembly.dll, la liaison se produit correctement si vous exécutez myAssembly.exe. Toutefois, si une autre application exécute myAssembly.exe à l’aide de la méthode AppDomain.ExecuteAssembly, le runtime détermine qu’il myAssembly est déjà chargé lorsque myAssembly.exe demande la liaison à myAssembly. Dans ce cas, myAssembly.dll n’est jamais chargé. Étant donné quemyAssembly.exe ne contient pas le type demandé, un TypeLoadException événement se produit.
Pour éviter ce problème, assurez-vous que les assemblys qui composent votre application n’ont pas le même nom d’assembly ni placent les assemblys portant le même nom dans différents répertoires.
Remarque
Dans .NET Framework, si vous placez un assembly avec nom fort dans le Global Assembly Cache, le nom de fichier de l’assembly doit correspondre au nom de l’assembly, sans inclure l’extension de nom de fichier, telle que.exe ou .dll. Par exemple, si le nom de fichier d’un assembly est myAssembly.dll, le nom de l’assembly doit être myAssembly. Les assemblys privés déployés uniquement dans le répertoire d’application racine peuvent avoir un nom d’assembly différent du nom de fichier.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
