If you have used TFS team build, you know that MSBuild creates a default label and build number/name with the following format:
Build Definition Name_YYYYMMDD_#
Where the # is an incremental number for the date. This format does not really provide any information about the version your are building. Nevertheless, the build number can be customized using the BuildNumberOverrideTarget. There are different approaches to achieve this. In this instance, we will take a very simple approach that will allow us to add the current product version to the build number without having to use a custom task which requires the deployment of a assembly on the build machine. The one item to always keep in mind is that the build number must be unique.
Open your TFs build project and add the following property group:
<PropertyGroup>
<VersionMajor>1</VersionMajor>
<VersionMinor>0</VersionMinor>
<VersionService>0</VersionService>
<VersionBuild>1</VersionBuild>
</PropertyGroup>
We just added a group of variables that indicate that the product we want to build has this version 1.0.0.1. You can change this to match your standard and your product version. Now add the target override as follows:
<Target Name="BuildNumberOverrideTarget">
<Message Text="Build number before [$(BuildNumber)]" />
<PropertyGroup>
<BuildNumber>$(BuildNumber)
[$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)]</BuildNumber>
</PropertyGroup>
<Message Text="Build number after [$(BuildNumber)]" />
</Target>
With this override, we are basically indicating that we want to append our version number to the TFS build number. We decided to keep the TFS build number to continue to provide a unique label/number to the build. The messages in the override log the build number before and after the change. If you check in your changes and queue a build, you will see that the build number has changed to this new format:
Build Definition Name_YYYYMMDD_# [MAJOR.MINOR.SERVICE.BUILD]
You will now be able to easily see the version associated to the build. When you are ready to build a new version, you will need to modify the property group. You should also know that if you try to build during the same day, you will probably get a non-unique build number error. This is because the build number that was generated was replaced by our custom build number, and the build process uses the "Build Definition Name_YYYYMMDD_#+1" to increment the build for the same date. To address this, you can add a parameter and append it to the build number as follows:
The build label parameter should be added to the MSBuild command-line arguments as follows:
/p:BuildLabel=001
The custom build task should address this limitation, but this is part of a different blog entry.
I hope this is helpful.
<Target Name="BuildNumberOverrideTarget">
<Message Text="Build number before [$(BuildNumber)]" />
<PropertyGroup>
<BuildNumber>$(BuildNumber)$(BuildLabel)
[$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)]</BuildNumber>
</PropertyGroup>
<Message Text="Build number after [$(BuildNumber)]" />
</Target>
