Update: I realized shortly after I posted this that theTfsVersion task reports the latest changeset present in a particular location within the build server’s workspace…not on the server.  Rather than re-write the task to interrogate the server, my short-term approach is to set up the (msbuild) call to my custom task like this – notice the “Get” ahead of TfsVersion that ensures we are looking at an up-to-date changeset number…rather than the one present in the workspace by virtue of the last build.

—

If you feel the need to customize your TFS Team Build number, it appears there are some (non-obvious) rules for doing so.  I wanted to add the latest changeset number (scoped to the branch I was building) on to the end of the build number as a suffix.  I’m using a combination of the TfsVersion task from the MSBuild Community Tasks and a custom task called within BuildNumberOverrideTarget.

My first cut was to simply take the default generated build number (like Dev_20071231.4) and add an underscore followed by the changeset number.  Like, say, Dev_20071231.4_335.  This works…exactly once.  After that you get the following error message:

TF42054: Team Foundation could not start the build. Please check the event log on the build machine for additional information.

None of the tracing flags for MSBuild seem to shed any light.  Your build type is basically toast, until you delete the build (and change your build number customization logic.)  Then I discovered that this was, at least to some degree, a known issue.  What I don’t think is so well understood is that even if you take complete control of your build number generation, you really want to leave an incrementing number at the end of the build number so that:

1. You can guarantee uniqueness even when every other component of the build number remains the same – since Team Build requires this.
2. To accomodate the fact that before you get a chance to customize the build number, Team Build runs parsing logic on the last build to try to determine what the new (default) build number should be.  If this parsing logic fails, you’ll get the above error. 

Ultimately I wound up generating something like this: Dev_1.0_20071231.44.2.  It has these components:

• Build type
• Release “friendly name” (any string)
• Date stamp
• Latest changeset number for the branch
• Incrementing number

I borrowed from the sample here, and wound up with this.  I’ll write more shortly about whether there are any behavior differences to be aware of in TFS 2008.