Strong Name Scenario 

The following scenario outlines the process of signing an assembly with a strong name and later referencing it by that name.

1. Assembly A is created with a strong name using one of the following methods:

Using a development environment that supports creating strong names, such as Visual Studio 2005

1. The development environment or tool signs the hash of the file containing the assembly's manifest with the developer's private key. This digital signature is stored in the portable executable (PE) file that contains Assembly A's manifest.

2. Assembly B is a consumer of Assembly A. The reference section of Assembly B's manifest includes a token that represents Assembly A's public key. A token is a portion of the full public key and is used rather than the key itself to save space.

3. The common language runtime verifies the strong name signature when the assembly is placed in the global assembly cache. When binding by strong name at run time, the common language runtime compares the key stored in Assembly B's manifest with the key used to generate the strong name for Assembly A. If the .NET Framework security checks pass and the bind succeeds, Assembly B has a guarantee that Assembly A's bits have not been tampered with and that these bits actually come from the developers of Assembly A.

   Note

   This scenario does not address trust issues. Assemblies can carry full Microsoft® Authenticode® signatures in addition to a strong name. Authenticode signatures include a certificate that establishes trust. It is important to note that strong names do not require code to be signed in this way. In fact, the keys used to generate the strong name signature do not have to be the same keys used to generate an Authenticode signature.

See Also

Reference

Strong Name Tool (Sn.exe)
Assembly Linker (Al.exe)

Other Resources

Creating and Using Strong-Named Assemblies