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 à nom fort a un nom entièrement qualifié qui inclut le nom de l'assembly, la culture, la clé publique, le numéro de version et, éventuellement, l'architecture du processeur. Utilisez la propriété FullName pour obtenir le nom complet, souvent appelé nom d'affichage, 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 avec un nom fort appelé myTypes peut avoir le nom qualifié complet suivant :
myTypes, Version=1.0.1234.0, Culture=en-US, PublicKeyToken=b77a5c561934e089c, ProcessorArchitecture=msil
Dans cet exemple, le nom qualifié complet indique que l’assembly myTypes a un nom fort avec un jeton de clé publique, a comme valeur Anglais (États-Unis) pour la culture et a comme numéro de version 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
L'information ProcessorArchitecture autorise 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. Ceci s’appelle une liaison qualifiée 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’assemblys sans tenir compte de la casse lors de la liaison à un assembly, mais il conserve la casse utilisée dans un nom d’assembly. Plusieurs outils du SDK Windows gèrent les noms d’assembly en respectant la casse. Pour de meilleurs résultats, gérez les noms d’assemblys comme s’ils tenaient compte de 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é de l’assembly, qui est constituée du nom, de la version, de la culture et du nom fort de l’assembly, 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é. Comme myAssembly.exe ne contient pas le type demandé, une TypeLoadException 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.