From Dan Mabbutt,
Your Guide to Visual Basic.
FREE Newsletter. Sign Up Now!

In the article about gacutil.exe, the Global Assembly Cache utility, I mentioned that,

"Shared assemblies must have a "strong name" consisting of the name of the assembly, the version, a 64 bit hash of a public key (called a 'token') and the culture. To create a strong name for an assembly (that is, to generate a public/private key pair), you'll have to use another utility called sn.exe."

We're digging into the .NET Framework toolbox in this series, so in this article, we'll dig deeper into the strong name utility, sn.exe. There's a lot more to strong names and sn.exe.

You can think of a strong name as the .NET Framework equivalent of the old COM GUID. GUID expanded into "globally unique identifiers" and that was just about the only real advantage they had. They were just 128-bit numbers that were created by a mathematical process that made them unique. But strong names are created using two cryptographically related keys called the public key and the private key. This gives strong names a whole new dimension of capability over the old GUIDs.

Being more exact, a strong name consists of a set of related data as follows:

• The friendly name of the assembly-which is just the name of the assembly minus the file extension.
• The version number of the assembly.
• The public key value-created using sn.exe.
• An optional culture identity value used for localization.

And perhaps most significant:

• An embedded digital signature that is created from a hash of the assembly's contents and the private key value. This is one big reason for having a 'strong name'. More on this later.

Before you can do any of this cool stuff, you first have to generate public/private key data using the .NET Framework utility: sn.exe. The sn.exe utility will create a file ending with the *.snk (Strong Name Key) file extension. This file contains the values of two mathematically related keys. These are the public key and the private key. The VB.NET compiler can record the full public key value in the assembly manifest.

The compiler will also generate a hash code based on the contents of the entire assembly including the IL (intermediate language) code and the metadata. A 'hash code' is a numerical value that can guarantee that the content of the assembly is the same. The hash code can be regenerated from the assembly and if the assembly isn't bit for bit identical, the hash value won't be the same. That means that if somehow any aspect of a .NET assembly has changed, the hash code will detect the change. The hash code is encoded by the private key data in the *.snk file to create a digital signature in the assembly's CLR header data.

The use of strong names goes way beyond the simple function of COM GUIDs and also provide protection against someone tampering with your assembly's contents. So it's a good idea to give every assembly a strong name, even if it isn't added to the GAC.

Note that the private key is not in the manifest. It's used to digitally sign the contents of the assembly (that's the process described above) but it isn't part of the manifest to maintain security. Public/private key cryptography can guarantee that no two organizations or individuals will have the same identity with .NET. But the most immediate effect goes back to where we started. Once a strong name is complete, the assembly can be installed into the GAC as a shared assembly.

Here's a quick demo of the process of generating and using a strong name.

We start off with our target utility, sn.exe as step 1! To create a public/private key file, open a Command Prompt window (and make sure you have changed the Windows Path using the SDKVARS batch file ... see the first article in this series for a detailed explanation). Change to a convenient directory - you might want to create a new one just to make things clean. You can then generate a file named MySNFile.snk file using the command:

sn -k MySNFile.snk

You can use the public/private key pair that is contained in this file in any number of assemblies. Your whole company could use the same file, or you can create one just for your own work.

Now, create and complile a program ... any program ... using Visual Studio just as you ordinarily would. Switching back to the DOS box, use the ILDASM utility to view the manifest for the new assembly file for your program. Scroll down to the section of the manifest that describes your program. If your program is a standard Windows program named MyApp, the section will start with the line:

.module MyApp.exe

Because you're going to be looking for a change in the manifest, you might even want to copy this section into Notepad for easy comparison.