Assembly versions management

What is Assembly version and how to control it?

Each assembly has a version number. The version number can be found in the AssemblyInfo.cs file in your VS.NET project. This file contains general information about the assembly using set of attributes such as: AssemblyTitle, AssemblyDescription, and of course AssemblyVersion.

AssemblyVersion attribute specifies the version number of the assembly.

(Unlike AssemblyFileVersion which will be explained later)

The format for the Assembly version is: <major version>.<minor version>.<build number>.<revision>

From msdn:

Major : Assemblies with the same name but different major versions are not interchangeable. This would be appropriate, for example, for a major rewrite of a product where backward compatibility cannot be assumed.

Minor : If the name and major number on two assemblies are the same, but the minor number is different, this indicates significant enhancement with the intention of backward compatibility. This would be appropriate, for example, on a point release of a product or a fully backward compatible new version of a product.

Build : A difference in build number represents a recompilation of the same source. This would be appropriate because of processor, platform, or compiler changes.

Revision : Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. This would be appropriate to fix.

It's important to note that these numbers mean whatever you want them to mean, that is you can say: "These changes are huge and important so I will change my major version number". Or you could say: "Well these features are not that important so I will change my minor version".

So we will change the major or minor version numbers when we do a change that is not compatible with the code before, such as : adding or removing parameters to a function.

We will change the build and revision version numbers when the changes are like bug fixes or internal code changes.

In order to control the version you can use the AssemblyVersion in the following ways:

1. Specify the entire version number such as:

[assembly:AssemblyVersion("1.3.250.1")]

This will specify that the major version is 1, the minor version is 3, the build version is 250 and that the revision number is 1.

2. Specify the major and minor versions only:

[assembly:AssemblyVersion("1.3.*")]

This will specify that the major version is 1, the minor version is 3and the build and revision are the defaults.

3. Specify only the major minor and build such as:

[assembly:AssemblyVersion("1.3.25.*")]

This will specify that the major version is 1, the minor version is 3, the build version is 25 and the revision version is defaults.

The defaults are being calculated like this:

If the version attribute is set to "1.0".*" the vs.net will calculate the version number as: 1.0.X.Y where X is the number of days since 1/2/2000 and Y is the number of seconds since last midnight divided by 2. Simple right?

Assembly version number at runtime:

The assembly's version number, which, together with the assembly name and culture information, is part of the assembly's identity. The number is used by the runtime (The CLR) to enforce version policy and plays a key part in the type resolution process at run time.

Note: When the assembly is one without a strong name there is no version checking. So the runtime will not look for an assembly in the GAC if there it doesn't have a strong name.

When two assemblies differ in their version number, they are considered by the runtime to be completely different assemblies.

Version checking only occurs with strong-named assemblies.

The version of a referenced Assembly is part of the clients manifest (as well as the public key token). So When the runtime tries to locate an assembly (This process is called probing) it (the CLR) checked that the Assembly it tries to load is identical to the one which the application was built with.

Here is a sample of such a client's manifest with a reference to a shared assembly:

When a client application adds the shared assembly as its reference, the shared assembly’s public token as well as the version number are recorded at the client’s manifest.

Let's see an example of this:

Let's say we have a Class library project called 2, and in the AssemblyInfo we are writing:

[assembly: AssemblyVersion("1.0.0.1")]

And let's say we have a Console Application named 1 which has a reference to the 2.dll file from our Class library project called.

Now suppose we deployed this 1 Application , and there is no 2.dll in its bin folder, but there is a 2.dll in the GAC. If we try to run this app everything is just fine. But if you change the version number to:

[assembly: AssemblyVersion("1.0.0.2")] and insert this new complied dll to the GAC, and try to rerun our 1 application, we get the following error: