How to automatically version C# builds in TeamCity?

Question

I’m wondering how to automate the versioning of my .Net/NuGet project that is being build with a current TeamCity build server.

What I do right now: My C# solution is checked in a repository and I have (and want to keep) two build jobs: stable and experimental. A stable build is triggered by commits on the master branch, commits on all feature branches trigger an experimental build. I use the special branch master-dev to accumulate changes, before I eventually merge it back into master to trigger the next stable release.

When it comes to versioning my project, I am using the following versioning scheme: «major».«minor».«buildnum» for stable builds and «major».«minor».«buildnum»-Experimental for experimental builds. So far, I set the major and minor versions in a system variable, use the “AssemblyInfo patcher" build feature to patch my AssemblyInfo.cs accordingly, and pass the version as a parameter to the “NuGet pack” build step. This works, but it has two annoying disadvantages:

• The is not synced between both jobs and increases much faster for experimental. Whenever I release a stable version, I basically have to “downgrade” all users of the experimental version to the stable version, because the former is strictly higher.

• The version number has to be updated in TeamCity after every stable release.

To simplify my workflow, it would be awesome if I could a) automatically synchronize the build numbers between both jobs and b) automatically update the minor version after every “stable” build. Optimally, I would also like to store the version number in the repository (instead of maintaining a TeamCity variable). Much like the Maven deploy/versions plugin, the “stable” build job would then need to update the version and push the change to the repository (without triggering a new build).

I did neither find a tool that solves these annoyances for me (maybe it is possible to develop a small tailored TeamCity plugin for this purpose), nor have I managed to find any real advice on how to solve these versioning issues differently… am I missing the obvious? What are the best practices of others to simplify/automate the versioning of .Net/NuGet builds in TeamCity?

Thanks for any pointer!

Answer 1

One pattern I like to use is to use a powershell script to update the SolutionInfo or AssemblyInfo files before the build. Then when the build is complete commit the changed files.

It would not be difficult to change that pattern to get latest just before updating the file, update the file, then immediately commit the change to help minimize any risk of having a version number sniped by parallel builds.

I've seen some people say you shouldn't have the build server commit into source but I disagree. Having the version number in the source means everything you need is in the source.

Answer 2

What your looking for is possible but you'll need to write some code to get it going.

I use a pattern similar to twisted mentat but without committing the version number back into revision control.

Depending on the project I either have a C# program, batch script, or powershell script I use to update the version number of all assemblies and binaries. I keep these scripts in revision control of the project there are for in a folder named factory. Normally under the name uvn.extension (example unv.ps1) where uvn stands for update version number.

Generally the version format I use is <major>.<minor>.<patch>.<revision> where revision is the last commit number. However within revision control the <revision> digit is always set to a zero.

When the time for a new release is approaching I'll manually run uvn.ps1 with the new version keeping the <revision> digit set to zero and commit the update files to revision control.

For TeamCity the first build step is then to run the uvn script. For the TC build step to determine what version to use it greps for the current <major>.<minor>.<patch> versions found in the source. For the <revision> digit it is set up to use the revision number of the commit it is building. The next build steps take care of compiling, packaging, testing. I do not commit the changed code back into revision control.