Assembly Version Numbers and .NET

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:

C:\path\to\updateversion\UpdateVersion.vbs “$(ProjectDir)”

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).

9 thoughts on “Assembly Version Numbers and .NET

  1. This technique of creating the build version using the [Year][DayOfYear] will not work for more than 2065…(of course I am not too pessimistic)….Any other solution.

  2. I’m getting an error when running this in the pre-build event. It exited with code 9009. I’ve tried numerous attempts to get it to work.

  3. The exit code 9009 could be a problem with the working directory. Have you checked that you’ve got the script and UpdateVersion console app extracted correctly and that all of the paths are correct (including the path in the VBS file).

  4. very nice tool it realy helped me, thank you,

    for 9009 error I think your path has spaces in it make sure you quoted your the whole path

    “C:\document and settings\admin\my documebts\UpdateVersion.vbs”

  5. Thanks for this. I also hit the 9009 thing, but editing the paths in the .vbs took care of that. Then it began to fail silently. I finally realised (after a whole 5 minutes) that I’d succumbed to the idiot’s mistake of copy/paste.

    From your post – it’s meant to be $(ProjectDir) not ($ProjectDir). Doh. (Also, fancy quotes aren’t normal quotes).

    Thanks again.

  6. two more things –

    line 249, VersionCalculator changed to:
    newBuildNumber = int.Parse(string.Format("{1:000}{0:00}", (d2.Year - 2000), d2.DayOfYear));

    else, being 2010, I just lose any year for BuildNumberType.YearDayOfYear revisions. I also don’t expect to need this past 3000.

    and updated the .vbs to this so as to not require a hardcoded path – assuming .vbs and .exe are in a folder called /build in the solution dir, and projects live in subdirectories.

  7. Thanks Matthew, I’ve updated the blog post with the correction to the ProjectDir variable on the command line.

  8. Pingback: How to: How to have an auto incrementing version number (Visual Studio)? | SevenNet

Leave a Reply

Your email address will not be published. Required fields are marked *