Last time I posted on MSBuild and TeamCity I showed how you could use it to deploy remotely in Deploy with MSBuild and custom targets Part 1 and Part 2. There are one issue that’s always a part of professional projects - version handling. I will show you a way to let the version get into the assemblies and trickle through all build steps all the way to the production package. In the first part I will concentrate on getting the version number into the assemblies while keeping unit test feedback, where currently running tests are directly visible in TeamCity.
Setting the version in TeamCity
First off is to set the version and build number in TeamCity. This is one of the easiest parts. Just go into the General settings for the project and set up the version number format and the build counter setting. like this:
Now we have something to base our versioning on, the first part 1.0.2. are static and you update that manually as you start a new release, etc. The last {0} will give you a build number, you get the idea.
Getting the version number to the assemblies
Next step is to make sure the version number from TeamCity is used to build the assemblies and added instead of the Assembly, File and Product Version set in the visual studio project properties. But first some background.
When the assemblies are built version values are automatically set from AssemblyInfo.cs files. If nothing is set, it will get the value of 0.0.0.0, file version will get the same version as in Assembly Version and application version will follow the file version. More about this in Assembly version, File version, Product version. The basics is that if we want to control the version we must make sure the AssemblyVersion attribute is in there. I would suggest setting it to 0.0.0.0 to make it easy to identify if anything fails to update. You could even have safeguards for it in code, aborting execution if the version is zeroed.
Now you have to make sure you change this number after the checkout but before the build has started. This calls for a shift from solution building to using MSBuild. But for the basic solution to build you only need one line of MSBuild script:
<MSBuild Projects="Software.sln"
Targets="Rebuild"
Properties="Configuration=Release;" />
That’s easy enough. Moving on to the version, we first collect the AssemblyInfo.cs files in the solution and then rewrite the version number with the TeamCity number. As it happens, there are a build property available containing the TeamCity number: $(BUILD_NUMBER). To get the build number into the assembly info we can use a task called FileUpdate that is part of a collection of open source MSBuild tasks, it will look like this:
<!— Collect the Assembly info files in the solution –>
<ItemGroup>
<AssemblyInfoFiles
Include="**/Properties/**/AssemblyInfo.cs;" />
</ItemGroup>
<!—Identify current AssemblyVersion and replace -–>
<FileUpdate Files="@(AssemblyInfoFiles)"
Regex=’AssemblyVersion\(“.*”\)\]’
ReplacementText=’AssemblyVersion(“$(BUILD_NUMBER)”)]’ />
This will get the desired result, with all assemblies carrying the correct version number. However, it will also give as a new problem; we now loose the unit test feedback in TeamCity, but we can solve that in the next step.
Unit testing with feedback
When you move from solution based execution to MSBuild based, the first issue you come across is that the unit tests are missing. The natural step is to make the MSBuild script execute them. Normally you would call nunit-console or maybe the NUnit task. But that will only give you a file to display as an artifact. Not the direct and continuous feedback you get from TeamCity. Fortunately TeamCity will provide a unit test runner task that can be used instead. The following lines need to be in the MSBuild script:
<!-- Integreate with TC's nunit runner –>
<UsingTask TaskName="NUnit"
AssemblyFile="$(teamcity_dotnet_nunitlauncher_msbuild_task)" />
<!-- Select the assemblies to test –>
<ItemGroup>
<TestAssemblies Include="**/release/*UnitTest*.dll;"
Exclude="**\obj\**;" />
</ItemGroup>
<!-- Execute the tests –>
<NUnitTeamCity Assemblies="@(TestAssemblies)" />
Read more about the NUnitTeamCity task on the TeamCity wiki, where you find information on how to execute it in 32bit, categories, on specific versions of NUnit, etc. Now we have all the parts to handle versions and still get the feedback. This also opens up some more opportunities as we now execute the build from MSBuild. We can do some pre- and post-processing around the build like zipping up files or exchange files or data after checkout but before build.
Next step is to get the version numbers across to the next project and use it for packaging as well as labeling our builds in subversion.
// Håkan Reis