Tips for Fast Team Build Script Troubleshooting
By default, Team Builds perform a cleanup of the folder used by Team Build as the local workspace for the Build Type being executed. Then on top of that it actually deletes the workspace definition and as if that were not enough, the Source Control 'Get' operation is executed with the 'force get' flag, which means that, even if according to the server, the latest version of the files being retrieved from Team Foundation Version Control already exist on the local workspace of the Team Build Server, they will be retrieved again.
As you can see, there is absolutely no doubt your Team Build will be working with the latest version of the source files. Which is great; that is probably how you are going to want most, if not all of your Team Builds to work. But for some build types it may take several minutes just to get the source code from the server and probably a similar amount of time to produce the binaries. Situations like this, where there is a lot of code to retrieve and compile are probably going to require some customization of your build script(s), maybe even include some custom MSBuild tasks and when it is time to troubleshoot issues with your script while executed on the Build Server, (i.e. when you find it useful to add /v:diag to your TFSBuild.rsp file) believe me, you are going to wish for a faster download of the source to the Build Server. And this is easy to achieve, since most likely you are going to be troubleshooting only your build script and not any source code, and even if your changing source code, you can easily tell Team Build to not perform any cleanup and only retrieve the files that are newer on the server than in the local Team Build workspace. Simply add the following XML to the <PropertyGroup> defined at the top of your TFSBuild.proj file:
<
SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
Then when you are done troubleshooting your script, don't forget to remove these lines and run your build one more time to make sure the change has no impact.
Another thing to keep in mind is that again, by default, the workspace definition for a Team Build Type is a copy of the workspace selected from the drop-down in the 'Select and order solutions to build' page of the 'New Team Build Type Creation Wizard'. Which means that if you do not select a workspace and only select solutions from the list, every time you execute your Team Build it will retrieve all the files from root of the Team Project's Source Control repository, even files that are not needed by that particular Team Build. To prevent this from happening and therefore reducing the time it takes to retrieve your source files from the server, it is a good idea to always review the WorkspaceMapping.xml file of your Team Build Type right after creating it and make sure you only have mappings for the folders you need for that one Team Build Type.