Scénario de nom fort
Le scénario suivant met en avant le processus de signature d'un assembly avec un nom fort, puis son référencement par ce nom.
- L'assembly A est créé avec un nom fort à l'aide de l'une des méthodes suivantes :
En utilisant un environnement de développement prenant en charge la création de noms forts, tel que Visual Studio 2005.
L'environnement de développement ou l'outil signe le hachage du fichier contenant le manifeste de l'assembly avec la clé privée du développeur. Cette signature numérique est stockée dans le fichier exécutable portable (PE) qui contient le manifeste de l'assembly A.
L'assembly B est un consommateur de l'assembly A. La section de référence du manifeste de l'assembly B inclut un jeton qui représente la clé publique de l'assembly A. Un jeton est une partie de la clé publique complète. Il est utilisé à la place de la clé publique elle-même pour économiser de l'espace.
Le Common Language Runtime vérifie la signature de nom fort lorsque l'assembly est placé dans le Global Assembly Cache. Lors de la liaison par nom fort au moment de l'exécution, le Common Language Runtime compare la clé stockée dans le manifeste de l'assembly B avec la clé utilisée pour générer le nom fort de l'assembly A. Si les contrôles de sécurité .NET Framework et la liaison réussissent, l'assembly B est assuré que les bits de l'assembly A n'ont pas été falsifiés et qu'ils proviennent réellement des développeurs de l'assembly A.
Notes
Ce scénario ne traite pas des problèmes de confiance. Les assemblys peuvent disposer de signatures complètes Microsoft® Authenticode®, en plus d'un nom fort. Les signatures Authenticode incluent un certificat établissant la confiance. Notez que les noms forts ne requièrent pas que le code soit signé de cette manière. En fait, il n'est pas nécessaire que les clés utilisées pour générer la signature de nom fort soient les mêmes que celles utilisées pour générer une signature Authenticode.
Voir aussi
Référence
Outil Strong Name Tool (Sn.exe)
Assembly Linker (Al.exe)