A while ago I got a call from a customer who wanted to understand what is the meaning of the version number’s in a compiled assembly and more than that, he wanted to understand how they are calculated. He expected that at least the build number were incremented every time a build is done, but that was not always happening…
As I guess you know, what that customer was talking about are the Major Version, Minor Version, Build, Revision (see Assembly versioning). This version number is physically represented as a four-part string with the following format:
<major version>.<minor version>.<build number>.<revision>. For example, version 1.5.1254.15632 indicates 1 as the major version, 5 as the minor version, 1254 as the build number, and 15632 as the revision number. The version number is stored in the assembly manifest along with other identity information, including the assembly name and public key, as well as information on relationships and identities of other assemblies connected with the application.
Of course you can manually specify the assembly version you want to use by setting it in the AssemblyInfo.* file, but if you leave to Visual Studio the task to calculate it, here is what happens (as usual don’t take this as granted forever, the algorithm might change in the future):
- Build: the number of days since 1.1.2000 (you can modify this start date by setting Software\\Microsoft\\ALink\\VersionStartDate). i.e. 1879 = 02.22.2005
- Revision: the number of two second intervals since midnight in local time; i.e. 31308 = 17:23:36 local time.
Regarding how Visual Studio updates the version number, the behavior is different depending is you are using Visual Basic .NET or C#: here is an excerpt from Team development with Visual Studio and Visual SourceSafe
Note For a Microsoft Visual Basic® .NET project with an AssemblyVersion set to “1.0.*”, the assembly version is only updated the first time the project is rebuilt within the Visual Studio .NET integrated development environment (IDE). The version number remains constant for subsequent rebuilds within the same instance of Visual Studio .NET. This does not represent a problem because the assembly version is for information only in assemblies that do not have a strong name. For strong named assemblies, you should avoid the use of wild characters in the AssemblyVersion attribute, as explained in the following section.
For C# projects with an AssemblyVersion set to “1.0.*”, the assembly version is updated every time the project is rebuilt.
Carlo
Quote of the day:It is by universal misunderstanding that all agree. For if, by ill luck, people understood each other, they would never agree. – Charles Baudelaire