Hints for expediting Team Build script development

One of the many elements of Visual Studio Team System that is so appealing is the build system.  Using the generic build wizard and scripts that it creates, Team Build provides an engine that can get your project from Team Foundation Version Control (TFVC), compile your Visual Studio solutions in your selected configuraitons, execute your unit tests, perform static code analysis, manage work item and changeset associations, and generate a multitude of outstanding reports. 

And this wizard based system works great if your working with .NET 2.0 projects developed and built with Visual Studio Team System tools.  If you're working outside of the sweet spot, perhaps working with .NET 1.1 or VB6, hitting a version control system other than TFVC, performing automated deployment of your applications, automating database deployment or other more advanced topics, Team Build can do it!  But not without a little work.

Team Build is based upon the MSBuild engine which means you can extend it to do almost anything.  Multiple community-based extensions have been created to do everything from manipulating IIS to changing file system attributes. And if you don't find the community extensions that you need, writing you own build tasks is relatively simple.

That said, even though developing advanced Team Build scripts can be fairly easy, it can also be rather time consuming.  Many of the mundane portions of the build script can take significant time.  If your build script pulls down large complex solutions that take awhile to simply fetch and compile your solutions.  In my current project, I am translating a PERL-based build script that packages compact framework and interacts with Borland StarTeam to retrieve external assemblies.  As such, most of the interesting things that I am working on happen after the all of the standard build stuff is complete.. and that process takes roughly 8 minutes when I am building both release and debug binaries.  Thus, modifying scripts and custom build tasks and then testing is a slow and tedious process.  Although I like my coffee breaks, consistently waiting for the mundane portion of the build is very inefficient.  So let me point you to several properties that can be specified for Team Build which will skip some of the mundane portions of the build:

• SkipClean
• SkipGet
• SkipLabel
• SkipInitializeWorkspace
• SkipPostBuild
• SkipWorkItemCreation

You can probably guess what they mean so I won't bore you with details.  But I will point out how easy it is to skip the portions of the script that aren't actively being used while you develop.  In my case, most of what I am currently working on takes place after the build; hence, I can skip clean through initialize workspace by simply overriding these properties.  This can either be done in a property group in your .proj or .targets files, or by overriding them from the MSBuild response file.  Following is what my TFSBuild.rsp file contains when I'm debugging portions late in my build scripts:

The /v:diag enables diagnostic-level verbosity in the logging.  Although it results in extremely large build log files, they are very useful when developing and troubleshooting complex build scipts.  Remember that once you've completed the script, your should delete these settings - or at least comment them out with a preceding #.

Note that skipping the clean through workspace targets doesn't skip the compile, but since the compile should already have up-to-date binaries from the last build before setting "Skip*" to true, the compile should be a very short step.

A quick word of warning...  When you use TFSBuild.rsp to override these or any other propeties, remember that you've done so.  Although that may seem obvious, when you're deep into development and debug in your .Proj and .targets files, it is easy to forget that the .rsp is part of the equation and equally easy to miss the obvious when trying to troubleshoot how your properies are getting set in the script.  (Yes, this is from experience [:S]).