DCSIMG
About signing assemblies, GAC and friends - Ran Wahle's blog

Ran Wahle's blog

About signing assemblies, GAC and friends

About signing assemblies, GAC and friends

Recently I was asked by one of my colleagues to explain to a customer of his about signing assemblies, putting them into GAC etc. So I’ve  decided to put some terms in order, for you to understand what it’s all about.

I’ll try to make it as short as possible saving you allot of technical details and stating all problems you may have ran into.

What is a signed assembly?

A signed assembly is a .Net assembly (EXE or DLL) that has been signed during compilation.
It has been signed by a key file (usually with .snk extension which stands for Strong Name Key) that can be generated by visual studio or from command line (with StongName tool ).

You’ve probably came across a type declaration in a configuration file   looking like that:

type="NameSpace.class, Assembly, Version=VersionNumber, Culture=cultureName Or 
neutral, PublicKeyToken=SomeHashCode or null
" />

The assembly, when signed will have some value on it’s publicKeyToken attribute
at it’s name (instead on null).

 

Why sign an assembly?

Well, The only reason I see right now is that If you wish to put your assembly in the machine’s Global Assembly Cache (GAC) you must do so. The GAC demands that the assembly will have strong named and it can be provided by signing it.

What is GAC?

the Global Assembly Cache (i.e. GAC) is a place on the machine, where heavily used assembles can be located. The GAC allows as to have assemblies with the same file name differs by their versions. Some of you may have encountered the term “DLL hell” referring to DLL registration where different DLLs with the same file name couldn’t be registered together, the GAC then comes to solve that problem. GAC registration can be done by using GacUtil command line tool that comes with Windows SDK installation or with Visual Studio.

And why register my assembly to the GAC?

You may want to put your assembly into the GAC if the assembly is shared by more than one application. The .Net runtime will look for assemblies on GAC before it goes to the application working directory. Loading assembly is also more efficient from GAC than from a regular file system location. You must’ however be aware of versioning when deploying into GAC because redeployment with the same version may harm backward compatibility.

How do I sign?

Well, That’s easy. On visual studio’s solution explorer,  go to the desired project, right click
and choose properties, than go to “Signing” tab
Signing tab on visual studio 2010

You may want to browse for an existing SNK file or create a new one by choosing “New”

Choosing “New” on the combo box will cause a dialog box to pop, you can then state your SNK file name and choose, if you want, to protect it with password as shown below:
New .snk file dialog no visual studio 2010

SNK files can be shared between projects, you may note that Microsoft assemblies has the same publicKeyToken, that’s probably because of that.

OK – My assembly is signed, what problems do I face?

Singing an assembly requires that all project references will be from signed assemblies.
That is because when register your assembly to GAC, the runtime will search and try to
load all referenced assemblies from there too. Trying to reference a non signed assembly from signed assembly project will cause  a compilation error. The referenced assemblies doesn’t have to be signed with the same SNK
However, the other way around is OK,  You can have reference to a signed assembly from non-signed assembly, you’ve probably done so because all Framework assemblies are signed and registered to the GAC

One other problem you may face is when signing an assembly is when you already have references to it. When signing an assembly and replace the non signed assembly with the signed one, you change the assembly’s signature and therefore it becomes a whole different assembly “all of a sudden”. This will cause visual studio to raise errors because it didn’t find the referenced assembly,  Re-adding the signed assembly as a reference can solve the problem.
On production environment you have to make sure that you keep the non signed assembly on the application’s working folder.

Summary

In this post, I briefly explained the basics about signing an assembly and register it to the GAC.  At many stages when deploying an application you may come across this issue, I hope this post will help.

kick it on DotNetKicks.com

Comments

DotNetKicks.com said:

You've been kicked (a good thing) - Trackback from DotNetKicks.com

# August 21, 2012 12:23 PM

The Morning Brew - Chris Alcock » The Morning Brew #1173 said:

Pingback from  The Morning Brew - Chris Alcock  » The Morning Brew #1173

# August 22, 2012 11:33 AM

Paulius said:

Isn't the reason to sign assemblies to make them tamper-proof and provide the authenticity?

# August 22, 2012 10:45 PM

Ran Wahle said:

Well, in fact it is, however there's got to be a reason to do so.

Assemblies located in the GAC must be authenticated and tamper proof, even on that case you can decompile assemblies, change it's code and re-sign it.

In order to realy authenticate an assembly you can use  The authenticode feature (see www.sslshopper.com/microsoft-authenticode-certificates.html)

# August 22, 2012 11:28 PM

About signing assemblies, GAC and friends - Ran Wahle's blog | Dotnet Professional | Scoop.it said:

Pingback from  About signing assemblies, GAC and friends - Ran Wahle's blog | Dotnet Professional | Scoop.it

# October 9, 2012 12:22 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: