Generating version number in MSBuild

Question

We have a C# solution with a WiX installer and an MSBuild build script. We're in the process of migrating from SVN to Git.

As the fourth part of our version number, we want something that ascends with each build. Until now, we've used the SVN revision number for that. The MSBuild script defines a ProductVersion property, which included the SVN revision number as the final of the four numbers of the build version. However, we can't use that anymore, as we won't be using SVN anymore.

I've been trying to find a replacement for the SVN revision number, but I can't figure out what to use.

• Jenkins provides a build number that I could use, but I don't want to tie our versioning system to Jenkins.

• Jenkins also provides a timestamp, but it doesn't comply with Microsoft's version number restrictions: it's alphanumeric and kind of long, while the 4th number in the version should be an integer between 0 and 65535.

• We can set the AssemblyVersion to 1.0.* and let .NET fill in the rest. This works for our assemblies, but I can't find a way to inject this into WiX. We can fetch it from one of the assemblies once it's built, but our MSBuild script uses the <MSBuild> task to build the whole solution at once, so we're stuck in a Catch-22 where we need to run <MSBuild> so it can compile an assembly that we can use to fetch the generated version number, but in order to run <MSBuild>, we first need to have a compiled assembly so that we can fetch the generated version number from it.

• I could add a separate Target in the MSBuild file that compiles something (anything) and get the version number from that, and then do the actual call to the <MSBuild> task. But that just feels wrong.

Again, I don't really care what the number is, as long as it increments with every build. Something based on a timestamp would be fine. Any ideas?

Answer 1

The MSbuild Community Tasks contains a task named Version, it provides some algorithms to generate version numbers. It is very easy to use and customizable.

IMHO, it is better to use a number that ties your entire SDLC, so you can trace your deployed product to the build results, and these to the VCS, and so forth. I would recommend using jenkins build number, as Christopher Painter did.