Versioning Strong Names

Building on the code in the 4_Shared directory, this step uses the code in the 5_Versioned directory to create two separate versions of the shareable component, and it uses additional application-configuration options to demonstrate how an application can be made to run. A method in version 2.0.1.0 of Reverser.dll was deliberately made incompatible with the same method in 2.0.0.0 so that a Client that successfully called that method using version 2.0.0.0 would fail with the later revision.

To illustrate how version keys can change from one version of an assembly to the next, you will generate a new key pair using the Strong Name tool (Sn.exe) and place them in a file:

sn –k orgVerKey.snk

Now that you have a new private key, you are ready to compile both version 2.0 components, specifying the key file and the version number to be assigned. Again, you can do this by specifying the following attributes (again, shown for version 2.0.0.0):

[assembly: System.Reflection.AssemblyVersion("2.0.0.0")]
[assembly: System.Reflection.AssemblyKeyFile("orgVerKey.snk")]

If you run Ildasm.exe again on the two updated Reverser.dll files, you can verify that the assemblies are shareable, as indicated by the presence of a different .publickey property (because you used a different key pair from version 1.0.0.0) and an updated .ver property (2.0.0.0 or 2.0.1.0, depending on which one you look at):

.assembly Reverser
{
  .custom instance void 
   ... // orgVerKey.snk
  .publickey = (...}
  .hash algorithm 0x00008004
  .ver 2:0:0:0
}

See Also

Binding Policy | Packaging and Deployment Summary | Appendix A: Additional Packaging and Deployment Information | Appendix B: Packaging and Deployment Tools