After reading Jeff’s post, What’s in a version number anyway, I’ve been looking at better ways to use version info in .NET projects.
Usually, I tend to stick with the default version, and let Visual Studio automatically increment the revision and/or build number, though it’s not really much help for anything.
Although Visual Studio 2005 has a much improved build system, I’m still working with 2003 for a lot of projects, and got looking at ways to manage the version number in AssemblyInfo.cs with this.
The first thing I came across was the UpdateVersion application, by Matt Griffith, and a good related article on Codeproject called Managing assembly version numbers using Visual Studio .NET and Visual SourceSafe.
In .NET, the version number convention is:
(Major version).(Minor version).(Build number).(Revision number)
Usually, I set the major and minor version, and let the build and/or revision numbers auto-increment.
To make this more useful, I figured I’d change this so that the BuildNumber would be the date, in yymmdd format, and the revision number would be the date in hhmmss format.
This would create a version number looking something like this:
From this, we can see that the build was made on February 17th 2007, at 16:02:34, which is a lot more useful than something automatically generated, like 1.0.2253.32047.
Out the box, UpdateVersion didn’t offer this functionality, so I grabbed the source, made the relevant changes, and tried it out. After setting up a pre-build event in VS.NET to update the AssemblyInfo.cs before building, the following error began showing up:
Error emitting ‘System.Reflection.AssemblyVersionAttribute’ attribute — ‘The version specified ‘1.0.70217.160234’ is invalid’
Unfortunately, it didn’t like the new assembly format very much. A quick search later, and I came across Michael Sync’s blog, where he also experienced this problem and wrote about his findings. In summary, he says:
Be careful when you are assigning the version of your build. [assembly: AssemblyVersion(“65534.65534.65534.65534”)] is maximum.
This limitation is quite restrictive, and makes it impossible to use the format above, incorporating the date and time into the build. So, as an alternative, I decided on the following format:
(Major version).(Minor version).([year][dayofyear]).(increment)
Fortunately, UpdateVersion includes another build version option called MonthDay, though this calculates the build version based on the project start date, which is also passed in as a command line parameter, and returns the format [monthssincestart][dayofmonth].
Still not quite what I was looking for, I got working on the code for UpdateVersion again, and added an option to generate the build number based on the year and day of year. This now gives me something like the following:
…which tells me that this is version 1.0, last built on the 48th day of 2007, and built a total of 2 times, which is a lot more useful than just letting the numbers increment automatically.
The original version of UpdateVersion can be downloaded here, or you can also grab the modified version. This includes the option above, YearDayOfYear, which allows the build version to be generated using the year and day of year. It also includes some small modifications to Options.cs, changing the way that text strings are parsed to their corresponding enum values and making it easier to add new options.
It also includes a VBScript to make it easier to call UpdateVersion in your pre-build events. To update your AssemblyInfo.cs before building, simply add the following to your pre-build event in the project info:
This will automatically update your AssemblyInfo file with the generated version information, and is ideal for use with the YearMonthDayOfYear option (though perhaps not with the MonthDay option, as this generates the version information using the project start date, which will be different for each project).