When you choose to automatically generate a new version of your assembly at compilation, you have to set in the AssemblyInfo.cs file, this line :
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.0.*")]
But what do these automatically generated numbers mean ? Well, chances are you don’t care. But one day after using this features for years I decided that I would.
- The build number is the number of days since 01/01/2000
- The revision number if the number of 2 seconds periods since 00:00 of this day
So… To get the compilation date of an assembly from its version, you would have to do :
var version = Assembly.GetExecutingAssembly().GetName().Version;
var date = new DateTime( 2000, 01, 01 ).AddDays( version.Build ).AddSeconds( version.Revision * 2 );
This feature is great if your need some atomic versionning of a particular library for instance. Each program using your library has its own version and you don’t risk to break working feature in future release of your library. And if you want to force the use of a newer version of a library within a particular application, you can use some assembly redirection.
But you should also note that if you deploy your assembly in the GAC (like it’s required to do with Sharepoint), you will have tons of “garbage” versions of your assembly. And there’s not “easy fix” for that.