Considerations on using TFS 2008 with Visual Studio 2005

Published 27 August 07 03:55 PM | dmckinstry

Visual Studio Team System 2008 is an incremental release and not a revolutionary new product.  It is a more profound upgrade than the upgrade from Visual Studio .NET to 2003 but is still not as big or intensive as the upgrade to 2005.  Although there are some nice new features, compatibility is very important and seems to be very well done.  For example, you're probably aware that Visual Studio 2008 can target .NET 2.0, 3.0 or 3.5.  However I'm I'm here to describe how to use Team Foundation Server 2008 with the Visual Studio 2005 components.

Out of the box, Team Explorer 2005 works very well with most of the TFS 2008 capabilities.  Work Item Tracking and Version Control function the same as they always had for TFS 2005.  End users wouldn't even notice the difference, except in some rare cases the increased performance.

I haven't spent much time testing the project portal in TFS 2008 but it seems to by fully compatible.  Although if you choose to use WSS 3.0 or MOSS 2007 as the base for your project portal instead of the WSS 2.0 (used by TFS 2005), users of the portal will probably notice a facelift and a few new features.

The reporting system seems mostly unchanged and compatible.  I've only done a little testing with custom reports taken from 2005 to 2008 but what I've done works perfectly.  I did notice the addition of a "Policy Override Comment" to the ChangeSet table in the data warehouse...  We'll finally have some sanctioned method of reporting policy overrides!

One of the key reasons that many users will choose to move from TFS 2005 to TFS 2008 is the new build capabilities.  If you plan to maintain a user base of Visual Studio/Team Explorer 2005 users for some amount of time even though you're upgrading to TFS 2008, you'll need to plan ahead:

  • You will need to have at least one installation of Team Explorer 2008 to create and manage build definitions and build agents.  Team Explorer 2008 will also be required to lock down builds and keep them from getting deleted by your retention policies.
  • You must structure your build folders in TFS 2008 as you would have in 2005.  That is, you need to have a TeamBuildTypes folder under the root of your team project and that folder must contain a subfolder for each build definition.  The build directories in version control must match the build definition name.  For example, if you create a build definition named "DevCI", you would need a folder structure similar to "$/MyTeamProject/TeamBuildTypes/DevCI".
  • Your build directory must contain the standard Team Build 2005 files: TFSBuild.proj, TFSBuild.rsp and WorkspaceMappings.xml.  Note that these do not have to be the actual files you use for the build; they can be almost completely empty or the TFSBuild files can be the actual ones you use in your build process.  I think you might need to have at least a mock version of TFSBuild.proj but it certainly doesn't have to be the one that is used.  Remember that the workspace mapping is now handed by the 2008 Build Definition so the workspace mapping file itself is only needed to trick Team Explorer 2005.
  • Install the appropriate Visual Studio 2005 components on your build server.  Since Visual Studio 2008 can target .NET 2.0, this might seem counterintuitive.  Unfortunately, to use the Visual Studio 2008 components you have to upgrade the solution and project files to be 2008 compliant.  This obviously won't work if members of your development team are still using Visual Studio 2005.  Remember to install which every build components you will use from the Visual Studio 2005 products (e.g., Unit Testing, Code Coverage, Static Analysis, Web Testing, ...).

With these considerations, you should be able to make use of Team Explorer 2005 and TFS 2008.  You'll get all the benefits of the new build engine including continuous integration and retention policies but your end users may not otherwise notice the difference.  Users on Team Explorer 2005 will still get the build history and build initiation screens exactly as they had before.  Of course, Team Explorer 2008 users will be able to access the same data but will have a few more capabilities.



No Comments

This Blog

Microsoft VSTS Blogs

MSDN Forums

VSTS Community Blogs