Visual Studio (2010+) adds a much-requested feature: the ability to automatically increment assembly versions per build. (Prior to this, the only way to update the assembly version was to include a batch file, build script, or some other mechanism tied to the build machine that would update AssemblyInfo.cs.)
As a refresher, the assembly version resides in the file
Properties\AssemblyInfo.cs. The file contains assembly-level declarations, which is to say, annotations for various assembly-level meta-data. (If you ever need to add any assembly-level annotations, like configuration for Eazfuscator, this is the place to do it.)
At the end of the file, you will notice a lovely comment block and two attributes:
// 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.*")]
The comment indicates how you can specify auto-versioning of the assembly version. You might think “easy, let me update my file like so:”
But there’s a gotcha here: you need to specify only the AssemblyVersion attribute for the auto-incrementing to work. With this configuration above, you will still see an assembly version of “1.0.*”, strangely enough.
The correct configuration is:
Save, build, and everything will work.
“Hey, that’s great,” you might be thinking. “Let me just update this through the project properties > Assembly Information button in Visual Studio.” So you blank out the File Version fields, only to be greeted with this:
That’s right — Visual Studio will only let you enter a blank File Version through the AssemblyInfo.cs file, not through the GUI! (Thankfully, if it’s already blank, and you edit some other properties, Visual Studio won’t complain.)
The Generated Number
You might be curious to know how Visual Studio generates the resulting numbers. In fact, you may wonder why it doesn’t start at, say, 184.108.40.206 and increment to 220.127.116.11, etc.
The actual details are specified on this MSDN page. The summary is that:
- The build number (the third number in the version) is equal to the number of days since January 1st, 2000. So if today is January 23rd, 2012, that’s approximately a value of 4400.
- The revision number (the final number in the version) is equal to the number of seconds since midnight, divided by two.So a build at midnight will result in 0, while a build at 1am will result in a value of 1800.
The end result is that every build results in a different version number (unless you run two builds at the very same second). The other caveat is that, if you have a build machine, you need to make sure your machine times are synchronized. Or at least be aware of the fact that a build machine in a different timezone may generate a build that seems newer (or older) than it should be.