Ranjan Banerji

I have two computers on which I was working on a project and on one of them all of a sudden I started getting this error.  After hours of trying to figure out what went wrong I finally gave up and started to search the web.  I would have started the web search sooner but the errors surfaced soon after I upgraded to Visual Studio 2008.  Well VS 2008 had nothing to do with the error.  It turns out that on one of my two machines I ran a Windows update for a non critical patch.  I realized this after finding this post: http://www.boyet.com/Articles/SigningAssemblyLUA.html.

Thank you Julian M Bucknall.  You mention that you wasted 2 hours trying to solve this.  Well I wasted about 4.  I should have found your blog sooner.

Anyway, the solution is simple.  Give your user (whatever account you use to log onto your computer and work on Visual Studio) Full Access to the following folder: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

Right Click, Properties, Security Tab, Add your user and make sure it has full access.

In my opinion a commonly misunderstood feature in .Net is the concept of Assembly vs File Versions.  While .Net tried to resolve the issue of DLL hell by providing the concept of Assembly and File Versions I do not believe many people use them correctly.  In this post I am going to present my way of interpreting the differences and how I use File versions and Assembly versions.

Think, Don't Read

Now I am asking for trouble.  But here is my issue.  I often come across developers who make decisions based on what they read and not based on careful thought and analysis.  I hate when someone says let's do this because its a Microsoft Best Practice.  Why is it a Best Practice I ask?  Does it apply to your situation?  The reply I often get is "but its a Microsoft Best Practice."  Recently I interviewed about 10 people for a Java developer position.  I asked each candidate to tell me what "Spring" is and why should it be used.  The answers I got included:

• Everyone uses Spring
• Spring is a must for Java projects
• Spring is now almost a standard
• You cannot build a Java application without spring.

and many others.  But no one, not even one, told me what Spring was and why it was a good idea to use it.  And therein lies the problem.  A lot of us go by buzzwords, blogs, books etc and not by what we know by virtue of careful thought and analysis of the situation.  Hmmmmm! said the right way and I could sound like Yoda.  If only I were that cool.

File Vs Assembly Versions

Anyway, back to File Versions and Assembly versions. In this post I intend to talk about when to use or create a File Version vs an Assembly version.

File Version

File Version is a way to version your files (DLL) for any purpose you want.  Neither Windows nor the .Net Framework cares about this version.  So when you create this version and increment it you are the sole consumer of the information held in it.

Assembly Version

This is a way to version assemblies in .Net.  However, unlike File versions the assembly version is used by the .Net runtime and various .Net applications.   Applications use assembly version information to determine which DLL to bind to.  So if you have an application that binds to Assembly version 1.0.0.0 and then you drop Assembly version 2.0.0.0 without any change to the client application, the client application will continue to load version 1.0.0.0.  So even though DLLs are Dynamic Linked Libraries, in .Net the dynamic linking put in a simplified manner is to a specific version.

The Difference

An assembly with 2 File versions, say 1.0.0.0 and 2.0.0.0 are the same as far as the .Net Framework is concerned and as far as any application that uses the assembly is concerned.  However, an assembly with two assembly versions say 1.0.0.0 and 2.0.0.0 are treated as two different assemblies or versions of the same one.  If both assemblies exist in the GAC and yes both can your application will have to choose which one to use.   With File Versions only one can exist in the GAC.  One can get into many more technical differences between assembly and file versions but for this post this shall suffice.

Time To Think

Given this basic difference we can now think about (keyword being think) when to use assembly versions and when to use File versions.  When you rebuild an assembly you have to ask the question why?

1. Is it a nightly build during development?  You really don't have to care much about this.  A File Version increment at a minor level may suffice.
2. Is it a build for a new version?   If so:
   1. Does the new release change or add a new interface?  Yes?  Increment assembly version.  Why?  A changed interface implies that no one using this assembly in the past can use it as it used to use the previous version.  So effectively you have created a new assembly.  In order to prevent any confusion between the new assembly with its different interfaces you should create a new assembly version so that old applications continue to use the old assembly version and new ones can use the new assembly without any ambiguity.
   2. Does the new release provide a change such that you need to have the previous version still available for use to those who wish to use it?  Yes?  Create an Assembly version.  This way you can retain both copies of your assembly.
3. Is the new release a bug fix with no interface change?  Do a File version change.  Changing the assembly version does not help you in this case.  In fact it will be detrimental as you will have to tell all consumers of your assembly to bind to the new version.

The worst reason and a very common reason (unfortunately) for assembly versions is to maintain some form of tracking of your DLLs.  Assembly version is not meant for this.  Use File Version for such tracking.  If you use Assembly version changes for each build where there is no interface change or no real need for a new version you may end up asking for too much trouble for you may end up having to update all your client applications to bind to the new DLL.

So think carefully before make the decision to change the Assembly Version.

Oh! and by the way, reading is a good habbit :-)