Team Build Compatibility between 2005 and 2008

Buck Hodges

The following question came up today, and I thought it would be useful to post.

One thing I didn’t mention was what happens in the upgrade process when you move from a 2005 server to a 2008 server.  The 2008 server stores in the database some properties that were previously stored either in the tfsbuild.proj (build agent computer, build directory) and workspacemapping.xml (build workspace template).  As part of the upgrade process, we read those files and create build definitions for each tfsbuild.proj, build agents with the computer and build directory specified, and workspace templates on the build definitions for each workspacemapping.xml file.

Also, as Brian mentions in his post today about upgrading to TFS 2008 Beta 2, you will need to install the TFS 2008 build agent on the build computers.  The version of the build agent must match the server due to the changes that we’ve made.  You can install both on the same machine, but you’d need to change one to work on a different port (that’s easier with 2008 than 2005).


I know there is high compatibility between 2005 and 2008 with Team Explorer and TFS.  But there are big changes in Team Build.  What will someone see in 2005 Team Explorer when looking into Team Build on a 2008 TFS/Build Server?  Can I actually kick off a 2008 build from a 2005 client?  Can I review build history?  Anything else I should be aware of?

My answer

Using the 2005 client with a 2008 server, they will see things just the way they always have, and that means that they won’t see the build queue, build agents, etc.  They will need to use a 2008 client to edit the workspace mappings for a build, as the workspacemapping.xml file used in 2005 is no longer used.  To change the properties of a build agent, they’ll need to use the 2008 client.  Changing the build machine or build directory specified in the tfsbuild.proj file will have no effect because those properties are stored in the database in 2008.

They cannot queue builds from 2005, since it didn’t have any notion of a queue, but they can start builds from 2005 if the build will start immediately, just as it was in 2005.

If someone configures a build definition for continuous integration, it will work just fine with either 2005 or 2008 clients, because the CI intelligence is all in the server.

The 2005 client will show you the list of completed builds.

We’ve had internal teams that continued to use the 2005 client with the 2008 dogfood server, and they were successful with it.  The thing I would suggest is that at least one person on the team installs Team Explorer 2008 (it works side by side with 2005) so that person can change the settings that are not accessible from 2005.  With the internal teams, diagnosing issues with the build agent, such as account password expiration causing the agent service to stop working, was the part that was confusing because you can’t see the build agent in the 2005 TE.

The guidance on compatibility from Brian’s April post on the TFS roadmap provides the overall picture and describes the reverse situation (2008 client, 2005 server).

As Orcas is an adoption focused release, we have put a lot of emphasis on compatibility with VS2005.  We are striving for near 100% compatibility.  The Orcas client will be able to work with a VS2005 server and a VS2005 client will be able to work with an Orcas server.  There are only a few compatibility issues.

· Client side VS add-ins will need to be recompiled (or have policy changed) because the TFS OM assembly versions will change and add-ins will need to bind to the new assemblies.  The APIs themselves are generally not changing, so we don’t expect much in the way of code changes – just recompilation.

· Build is the only area where we plan to have some compatibility disconnects.  In general, most build operations – listing build definitions, starting and stopping builds, examining build reports, etc. will work both with 2005 client -> Orcas server and Orcas client -> 2005 server.  However, here are a few caveats:

1. An Orcas TFS server will only work with an Orcas build server – so you’ll need to upgrade your build server when you upgrade your TFS server.

2. For an VS2005 client to start a build on an Orcas server, the build definition needs to be stored at $/<TeamProject>/TeamBuildTypes/<name>.  In Orcas, you have more flexibility as to where to put them.

3. Changes made to properties in the .proj file that are in the database in Orcas will not be updated in the database and will no longer be in sync.

4. VS2005 will be able to start a build, but it can’t queue a build, see the list of builds in the queue, see the list of build agents, etc.

5. An Orcas client will not be able to create a new build definition on a TFS2005 server.

6. When starting a build, an Orcas client will not be able to change any parameters in the dialog for a TFS2005 Server.


Leave a comment

Feedback usabilla icon