Syncing the build number and assembly version numbers in a TFS build when using the TFSVersion activity

Updated 27 July 2013 - Here is a potential solution

Update 27 Sep 2011 – this seemed such as good idea when I initially tried it out, but after more testing I see changing the build number part way through a build causes problems. The key one being that when you queue the next build it is issued the same revision number [the $(Rev:.r) in the BuildNumberFormat] as the just completed build, this will fail with the error

TF42064: The build number 'BuildCustomisation_20110927.17 (4.5.269.17)' already exists for build definition 'MSF AgileBuildCustomisation'.

This failed build causes the revision to increment so the next build is fine, and the cycle continues. Every other build works

After a bit more thought the only option I can see to avoid this problems is the one Ewald originally outlined i.e. a couple of  new activities that are run on the controller, one to get the last assembly version and the second to override the build number generator that are run prior to everything else.

So I have struck out some bits of the post and made it clear where there are issues, but I wanted to leave it available as I think it does show how it is easy to get to point that you think is working, but turns out there are unexpected problems

[Original content follows]

I was asked recently if it was possible to make the TFS build number the same format as the assembly build number when you are using the TFSVersion community extension. The answer is yes and no; the issue is that the build drop location in the standard build process template is create before any files are got into the workspace from source control. So at this point you don’t have new version number, a bit of a problem.

A detailed description of one approach to this general problem can be found in Ewald Hofman’s blog on the subject, but to use this technique you end up creating another custom activity to update the build number using your own macro expansion. Also there will be some major workflow changes to make sure directories are created with the correct names.

There following instructions do not give the desired result for the reasons outlined at the top of this updated post

I was looking for a simpler (lazier) solution when using the TFSVersion activity and the one I came up with to just update the build name, and do it after the drop directory was created. So that I did not end up with two completely different names for the drop folder and build I just append the version number to the existing build number. This is done by re-running the Update Build Number activity. I added this new activity to example workflow logic from the TFSVersion documentation, ending up with something like

where the Update Build Number has the following properties

So we just append the newly generated version number to the existing build number.

string.Format("{0} ({1})", BuildDetail.BuildNumber , VersionNumber)

Note you can’t use the BuildNumberFormat.in this string format as this string contains the $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r) text that via macro expansion is used to generate the build number. The problems if this expansion if used in this string format you get the error

The revision number $(Rev:.r) is allowed to occur only at the end of the format string.

So it is easier to use the previously generated build number.

This also has the effect that drop folder retains the original name but all the reports contain the old folder name with the generated build number in brackets, and the Open Drop Folder link still works

I reasonable compromise I think, not too much change from a standard template.

Does not work as only alternate build work, see top of post

</Following Does not Work>