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 worksexactly 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:
-
You can guarantee uniqueness even when every other component of the build number remains
the same – since Team Build requires this. -
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.