Signing Your .Net Add-In

In my previous posting Converting VBA Auto Macros to an Add-In I described how to create a basic add-in and install it.  There's one additional item that I didn't cover in that posting related to the installation of your add-in.  When you install your add-in you'll get the warning shown below.  It is just a warning and can be ignored, but it's often misinterpreted as an error and it would be best to avoid it.

If you read the warning you'll see that it doesn't like you to use the /codebase argument with an unsigned assembly.  We have to use the /codebase argument with an add-in to get it to register correctly so it's not an option to leave it out.  The only other option is to sign the assembly, which is what I'll show you how to do here.

What is Signing? 
Signing is a way of creating a unique ID for your add-in.  This is also referred to as a "strong name".  Without signing your add-in there is the potential, although very minimal, of it conflicting with another .Net assembly.  A strong name consists of the filename, a key, version, culture (language), and processor type.

The concept of signing can also extended to serve as a security mechanism.  In addition to providing a unique identifier for the assembly it also identifies the make of the assembly.  Microsoft calls this Authenticode and the process is handled by Verisign.  This type of signing is not required and not something I'll discuss here.

Creating a Key
To sign an assembly you need to have a unique key to sign it with.  You generate a key using the .Net sn.exe (strong name) utility.  This utility is located in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin.  I would recommend creating a new directory for the resulting key because a single key can be used to sign all of your add-ins.  Here's an example of executing this utility from the command line.  (This is for Visual Studio 2008.  If you're using something else you may need to search for sn.exe.)

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\sn.exe" -k MyKey.snk

This is all shown below.  Note that because of the spaces in some of the directory names that the double quotes around the full command line are required.

 

If you have a version of visual studio besides one of the Express editions, you can use the Visual Studio Command Prompt to make this a bit easier because you won't need to know where the utility is.  This creates a cmd window where the paths are set to all of the various .Net related tools.  If you're new to Visual Studio, you open a Visual Studio Command Prompt window through the Start menu in the "Visual Studio Tools" list, as shown below.

 

In the Visual Studio Command Prompt you only need to enter:

sn -k MyKey.snk

Signing the Add-In
Now that you have the key, you can use it to sign your add-in.  To do that run the Project -> Properties... command, (the last command in the Project menu).  Pick the "Signing" tab, click the "Sign the assembly" check box and browse to select your key file.  Recompile your project and you now have a signed assembly.

Now when you run the regasm utility when installing your add-in you should see this and no more errors.

Using a signed Add-In

Using a signed add-in is no different than an unsigned one with one exception.  To use it you just need to copy it to the computer you want to use it on and register it.  That's the same process as an unsigned one, except you won't get the warning message anymore.  The difference to be aware of is if you want to replace the existing add-in with a newer version.  With an unsigned add-in you can just copy the new dll to the computer and everything is fine.  With a signed add-in you must re-register the add-in.  Signing ties the registration to the dll version so you need to re-register the add-in to update the version information in the registry to match the current dll.

(Thanks to Neil Munro for a question about the versioning that caused me to investigate this some more and update this posting.)

Comments

[Neil]

Brian, could you expand on the issues regarding signed assemblies and versioning. My understanding is that if you distribute strong named add-ins, each version (i.e. each build if versioning is on, which is the default) would require the user to unregister (or uninstall) the current add-in assembly and then register (or install) the new one. This negates updates via dll copy that can be accomplished with unsigned add-ins. Is that correct?

[darkfall gold]

Hey, I found your blog while searching on Google your post looks very interesting for me. I will add a backlink and bookmark your site. Keep up the good work!