TF42053: Build Machine and AllowedTeamServer

In the Day Job, we're moving from our dodgy, flakey, unsupported pilot TFS instance to our dodgy, flakey, supported production TFS instance. I foolishly volunteered to move our projects across and get all the builds working again.

Stage 1: Moving the Source

Of course, since Microsoft didn't deign to provide a tool to move repositories between servers while retaining history (no svndump for you!) this is pretty straightforward. A little care is required to make sure you don't accidentally pollute the repository with rogue files, but the basic process is as follows. I'll call the old TFS OLD, and the new one NEW.

1. Make sure everyone's checked their outstanding code in.
2. Create a new workspace in OLD, and map the root of the repository in this workspace to a new folder on disk.
3. Do a Get Latest to fetch all the source code.
4. Connect VS2005 to NEW.
5. Create a new workspace in NEW, and map the root of the repository in this workspace to a new folder on the disk.
6. Copy all the files from the OLD workspace to the NEW workspace
7. Take this opportunity to delete all those junk .vspcc files that you've accidentally checked in
8. Back in VS2005, add all the files using the Add dialog. Watch out that the default filter doesn't exclude things like DLLs, if you're checking those in.
9. Commit.

That's it - pretty straightforward.

Stage 2: Reconfiguring the Build Server

The next step is to reconfigure the build server to look at the production TFS instance. I'm not going to cover creating a Team Build type here, but if you do so and run it against your build server without changing the build server configuration, you'll see this message:

Yep - a build server can only connect to a single TFS instance.

Unlike most TFS error messages, this one is actually useful. If you follow it (to the letter) then it'll work. When you edit the TFSBuildServer.exe.config file, ensure that the server name is entered exactly as shown in the error message. It's quite picky. Then restart the build service.

After that, the build should work - except that it probably won't.

A variety of things can happen at this point. The problems I've heard about all seem to boil down to the workspace cache that the build server keeps. The symptom I saw was TFS showing the correct source download location during the CreateWorkspaceTask output in the build log, but then downloading the new source code to the wrong (ie. old) location.

The solution to this is to dig into the cache directory kept by the build server. It'll be in the following directory:

C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache\

Obviously, substitute <user> with whatever username your TFS build service runs as.

Look for a file called VersionControl.config. Open it up, and you'll see references to your old build location.

Simply delete this file, or rename it - and hopefully your build should now work.

Incindentally, if you know of any tools to move repositories between servers, then do let me know.