.NET Assembly Version Numbers

Version numbers on .NET assemblies are both simple and complicated stuff. This post will explain the details of the different version numbers on an assembly and what they are used for, then I will show how we can modify all of them on an existing assembly without access to the source code from which it was originally built.

The 3 .Net Assembly Version Numbers 

The simple story of version numbers is presented in the MSDN article Assembly Versioning.

• The assembly's version number, which, together with the assembly name and culture information, is part of the assembly's identity. This number is used by the runtime to enforce version policy and plays a key part in the type resolution process at run time.
• An informational version, which is a string that represents additional version information included for informational purposes only.

Ok, so an assembly has two version numbers, a real version number and a descriptive text thing, right?

Actually, no, it's not that simple.

Lets build a simple dll and look at the properties of the result in the file explorer:

File version and Product Version? Which is which?

Lets have a look at the AssemblyInfo.cs file:

The AssemblyInfo.cs has two version attributes by default. The AssemblyVersion and the AssemblyFileVersion. Lets set these two numbers to 1.1.0.0 and 2.2.0.0 as shown above and lets see what happens to the ClassLibrary1.dll properties after we build.

We can now see that the File version is changed as expected, but the AssemblyVersion number isn't shown at all, we will get to that in a minute. There's a field called Product version, which has the same value as the File version. The Product version is the same version number as Microsoft refers to as Informational version in the Assembly Versioning article. The informational version is set to the File version if not set.
We can set the Product Version by adding a AssemblyInformationalVersion attribute to the AssemblyInfo.cs file.

If we build again we get the result as expected.

Now that we know how to set and check the last two version numbers, how do we check the most important one, the one that the .Net runtime uses when it determine to load the assembly or not, the Assembly Version?

Its clearly not in the dll properties dialog we can access from the Windows Explorer. We can read the assembly version programatically by using the following code:

Version version = AssemblyName.GetAssemblyName("MyAssembly.exe").Version

Reading Assembly Version Number using Powershell

Depending on what version you used to build the assembly and what version of Powershell you have installed you may be able to use the same method from Powershell.

I used Visual Studio 11 and .NET framework 4.5 when testing this, thus I had to download and install Powershell 3.0 to check my assembly. 

When you have the right Powershell version you can do:

       [Reflection.AssemblyName]::GetAssemblyName('full path to the assembly').Version

Which is essentially just the same as calling it from C# code as shown above.

Reading Assembly Version Number using a Decompiler

If you don't have the right Powershell version then probably the easiest way to get the assembly version number is to use a tool such as Telerik JustDecompile which also will present the assembly version.

For assemblies we are using in a Visual Studio solution the easiest way is of course to simply look at the properties of the referenced assembly.

Just Informational?

So we have 3 version numbers. As mentioned the Assembly Version and Product Version are described in the MSDN article Assembly Versioning. The File Version and the Assembly version are documented here.

If we combine the information from these two articles we get:

1. Assembly Version - the real deal, the number that matters
2. File Version - a number that can be used to tell the developer what version the should have been if we had upped the assembly version number
3. Product Version - a text string that is just informational, doesn't even have to be a number at all.

However it turns out that the Product Version number isn't that free form after all as one could be lead to believe reading the MSDN documentation, at least not for all types of .NET applications.
I think that the Windows forms application team at Microsoft have had better days at work than the day they designed the System.Windows.Forms.Application class. This class has features that probably would be useful for console applications and others, while it at the same time has functionality that only makes sense in a Windows Forms application. A few warning signs that could indicate a need for a closer look at the Single Responsibility Principle.
Anyway this class also has a dependency on the Product Version string of the assembly, and remember, this is the version string that the MSDN says the following about :

The informational version is a string that attaches additional version information to an assembly for informational purposes only; this information is not used at run time.

Well this is simply not true for a Windows forms application.
Both the static properties UserAppDataPath and CommonAppDataPath that are used to get path to special folders are using the string stored in the Product Version property of the entry assembly.
Which means that should you decide to put any of the following characters in the version string '/ \ * ? < > |'  of your Windows forms application assembly you may quickly end up in trouble using the Application class.

.NET Framework 4.5 Version Numbering

Rick Strahl recently posted an article about the version numbers on the .NET 4.5 assemblies, and Scot Hanselman later posted another which in part responded to some of Ricks findings.
I think the fact that these .NET Masters don't immediately agree on such a seemingly simple thing as version numbers of the assemblies should tell us something about the real simplicity of the matter.
Reading Hanselman's post it looks as things aren't as bad as one could think when reading Strahl's post, but I do think Microsoft could have made things easier for us. As the Product Version number isn't supposed to be used for anything, why not put the 4.5 number there?
Then it would have been so easy to see that this is in fact a 4.5 assembly. On the other hand, when we see what Microsoft has done in the Window forms example just mentioned, who knows what else is dependent on that Product Version, even if it is not supposed to be in use by the .NET Framework.



Hacking assembly version numbers using ILDASM and ILASM
Quite recently I found myself in a situation where I had an application that was configured to load a plugin written by someone else. The author of the plugin had messed up the version number of the plugin he gave me and he didn't have time to fix it. The application refused to load the plugin, and I couldn't reconfigure it so I thought I just had to wait for a new plugin. Then it hit me that this version number have to be stored in the assembly somewhere and  it should be possible to change it, and in fact it is very possible to change all three version numbers of an assembly.

Ildasm.exe

Ildasm is the MSIL Disassembler which can read assembly files and turn them into a somewhat human readable text file + a .res file containing assembly resources.

The cool thing is that we can edit these two files and change the version numbers, then we can re-assemble the dll using Ilasm on these to files and getting a dll file again.

To dissamble the dll simply start the ildasm.exe <dll name>.
When the IL DASM application has started we can dump the contents of the assembly to two files by pressing ctrl-d and then check all boxes in the Dump options dialog that pops up.

Name the result in the save dialog that follows and then we get two files with the extensions .il and .res.
Both files can be edited in Visual Studio.

Changing the Assembly Version

To change the assembly version we open the .il file and search for a piece of il code that starts with .assembly followed by a comment and then the assembly name.

It will look similar to this:

.assembly /*20000001*/ ClassLibrary1

{

....

....

....   

  .hash algorithm 0x00008004

  .ver 3:3:0:0

}

The assembly version number is changed by simply editing the string after .ver and then save the .il file.

Changing the File version and Product version

Both the File and Production version can be changed by editing the .res file in Visual Studio 11.

If you open the .res file it will look similar to this:

Double-click the 1 [Neutral] node to open the resource editor

Change the Fileversion in the upper part. Notice that the PRODUCTVERSION is shown as 0.0.0.0 in the upper part because it is not a number. Edit the ProductVersion shown in the bottom to change it as text.

Save the .res file.

Create the modified assembly from the .il file and the .res file

To build a new assembly from the modified .il file and the modified .res file open a Developer Command Prompt as shown:

Execute: ilasm /resource:<resource file> /dll <il file>.
And we have changed the version numbers of our assembly file.