TFS Team Build can run forever

Problem: It is possible for TFS Server to lose track of a remote team build and believe that it is still running even if the build machine has not raised an event back to the TFS Server in a very long time (>36 hrs). It seems that the default timeout for a build is for the TFS server to wait forever.

Scenario: I was testing a team build that went awry. My build script deleted a large portion of the C: folder and hosed the machine (stop laughing). To stop the build (prior to learning that there is a TFSBUILD STOP command), I shutdown the build server. The machine was hosed and needed to be re-imaged. About 36 hrs later, I reviewed “All Builds” within Team Explorer and noticed that the TFS Server thought that the build was still running. So even after 36 hrs+, TFS hadn’t failed the build on a timeout.

Fix: I had to use the “TFSBuild.exe Stop” command to inform the TFS server that the build should be aborted. You should also run tf workspaces owner:* server:[MYSERVER] on the Build Server and the Client machine that initiated the build to update the workspace cache which will clean up any stray workspaces.

Comment: If you have a failure of a remote build machine during a build, you need to ensure that the build is cancelled on the TFS server or you may have a workspace collision when a new build is run when the machine is back up as the workspace’s local path is considered to be still “in use”. this “in use” status comes from the Build Machine or Client’s workspace cache being out of sync with the Team Foundation Server’s database. the tf workspaces command above will update the locaal cache from the server and clean this up.

Mike Ruminer has posted a step-by-step listing of the entire event on his blog.

The opening post

Ok, here’s the obligatory opening post that gives background and context to the rest of these rantings. I am a developer working for an insurance company. We are a Microsoft house, so I get to play with all of the “cool” and “new” stuff from them.

As this blog’s name implies, I often hit walls using their products. Now don’t get me wrong, Visual Studio and all of its siblings are my bread and butter. I love working with the tools, I just hate those times when I spend half of a day trying to figure out something that should be relatively easy. The worst part is when I finally figure it out, it seems like it shouldn’t have taken that long. I especially feel this way when my Dev lead is breathing down my neck about “deadlines” and “iteration plans”. I call that “getting burned”. Most of the time this is due to lack of documentation from Microsoft and little published knowledge from the wider user community.

The current project, and the one that lead me to start this blog, is a proof of concept to implement Microsoft Team Foundation Server. We want to use all of the features of it, but need to first be able to get a successful build process for our Continuous Integration plan going. This includes automated code generation (check out, generate code, check in, build project, repeat for next project) during the “team private build”. You would think that this is an easy thing to do. I did too until I started doing Google searches for information. I was amazed that certain specific TFS API related searches returned 1 or 2 hits. There is only a small amount of information out about TFS from Microsoft specifically geared toward working with the APIs and the SDKs aren’t much help either.

Since I seem to be what is called an “early adopter” of the TFS technology, I’m going to try to relieve the pain that some of you will potentially go through by posting small “snippets” of information that I read/figure out/am told about Visual Studio 2005 and Team Foundation Server. I will also be pointing to other blogs/sites that I feel offer good information. One of the biggies is Buck Hodges blog and the MSDN VSTS Forums which includes one of the first code samples pertaining to the Version Control API.

Since I work daily in VB.Net, most if not all of the code samples will be in VB.

So that’s it for the moment, more to come…