Build report:Changesets taking too much time to get populated?

A Team Build user had this problem the other day and I thought it would be a good idea to share this lil ‘tip of the day’..

As a part of the build process in team foundation build, we report changesets associated with each build. This is done primarily to help you quickly view what all checkins that went into this build with the name of the dev who made the checkin and his comments. This makes it much simpler to point out the possible cause of a build break..

But in cases where you have a huge number of changesets being reported (say around 5k of them)..this might take several minutes hence holding up your report and build. A very typical scenario would be when you have just migrated an existing project with an already existng store of changesets and work items and you have started a build. An interesting fact which causes this is, that we report changesets only between two ‘successful’ builds for a team project and for a build type. Pardon me for diverting from the topic but – the definition of a ‘successful’ build that we use in Team Foundation Build is a “build which has 0 compilation errors and has passed all tests included in the build” (Again we had a huge debate whether test results should or should not be included in determining a ‘successful’ build but we finally thought that any good daily build process should have this behavior – here is what Martin Fowler says about it ( I would love hear your thoughts on this though).

Ok so back to where we were – now that you have changesets taking several minutes to report and the matter is made even worse if the builds are failing – cause everytime you have to invest the same time to even debug what went wrong with the are some tips to help you..

1. Did you know that you can actually skip this step of getting changesets altogether in team build?

To do this you would need to edit the Microsoft.TeamFoundation.Build.targets file. You simply need to change the property value of SkipPostBuild to ‘True’. Here is what it would look like


Set this property to true to skip PostBuild target –>


SkipPostBuild Condition= ‘$(SkipPostBuild)’==” >true</SkipPostBuild>

But yes by doing this you would also be choosing to switch the automatic update of the associated work items with the changesets with the build number

2. But before even doing this – if the problem is simply that you need to debug the issue causing the build break – a better idea would be simply to do a desktop build (which does not get changesets or update work items).

Keep team building !!