Senior Service Engineer, Microsoft Visual Studio Team Foundation Service
When you upgrade from Team Foundation Server 2008 to 2010, one of the things you need to check is the compatibility of the tools that people rely on and use the server with. Without careful preparation this can have a significant impact on your user's experience after the server is upgraded.
As an example, when we upgraded the DevDiv TFS server which is home to more than 3,500 users - there were ~200 unique tools that were using the server which all had to be assessed for compatibility. We started by prioritizing them into four buckets:
To help the tool owners check compatibility, we had a cloned and upgraded server available that they could work against. They also had the option of installing TFS Basic in about 15 minutes by themselves and testing on their own workstation.
Perhaps the most difficult part of it all was identifying who actually owned the tools! Once we identified the owners, there was a weekly barrage of nag-mail to make sure they were ready. Here's an example of one of the status reports:
P0 Tools – 11 out of the 15 P0 tools have been tested and made compatible with TFS2010 and the other 4 are on track. P1 & P2 Tools – Good progress has been made with the P1 tools with almost half of them signed off. The other half have no owners or are not used by many people.
P0 Tools – 11 out of the 15 P0 tools have been tested and made compatible with TFS2010 and the other 4 are on track.
P1 & P2 Tools – Good progress has been made with the P1 tools with almost half of them signed off. The other half have no owners or are not used by many people.
The easiest way to identify tools that might be impacted is to look at the tbl_Command table in the TfsActivityLogging database.
SELECT UserAgent, SUM(ExecutionCount) as ExecutionCount FROM [TfsActivityLogging].[dbo].[tbl_Command] GROUP BY UserAgent ORDER BY SUM(ExecutionCount) DESC
SELECT UserAgent, SUM(ExecutionCount) as ExecutionCount
GROUP BY UserAgent
ORDER BY SUM(ExecutionCount) DESC
This will show you all the unique user agents that have accessed the server in the last 14 days ordered by the total number of commands. You can ignore w3wp.exe[*], devenv.exe, msbuild.exe, tf.exe, tfpt.exe, WINPROJ.exe, Excel.Exe, BuildNotifications.exe & vstesthost.exe - since they will all get upgraded along with the server & client installs.
The following table is a list of the common changes that will be required for your tools to be compatible with TFS2010:
Workaround / Recommendation
Incompatible client versions
If you are using the VS2008 object model, the server rejects requests from clients that don't have the "Forward Compatibility GDR" installed.
At the very least, you need to install VS2008 SP1 + the Forward Compatibility GDR on any clients that connect to TFS.
See this blog post for more details on supported forward and backwards compatibility.
You should upgrade and recompile your tools to use the VS2010 object model for full compatibility.
TFS2010 introduces a "/tfs/" virtual directory prefix in the default install. It is possible to install TFS at the root "/", or any other prefix.
When you install or upgrade the server, it is possible to install at the root "/". This configuration along with setting a default collection will allow tools with hard-coded server addresses to seamlessly continue to connect to the existing server.
Tools should not make assumptions about the structure of a server URL or hard-code the server URL. They should allow users to specify an arbitrary URL through a configuration setting.
TFS2010 introduces a new concept called "Team Project Collections" (TPC). To facilitate this, there is an extra identifier in the URL.
TFS2010 has a "Default Collection" setting which is stored in the TFS instance registry (/Configuration/DefaultCollection/). This is the collection that clients will get when they don't specify a collection.
When you upgrade a TFS2008 server to TFS2010, the default collection is set to the TPC containing projects from the upgraded server. When you use "tfsconfig import" to upgrade additional TFS2008 databases, the default collection is not changed.
Tools should specify an explicit TPC to avoid unintended consequences if the "Default Collection" of an instance changes.
Object Model changes
In the VS2008 object model:
In the VS2010 object model:
The VS2010 object model has many compatibility changes and bug fixes (e.g. improved memory usage).
You should recompile your tool against the VS2010 object model and add support for choosing & specifying a TPC name.
See Taylor's blog on the TfsConnection, TfsConfigurationServer and TfsTeamProjectCollection classes that replace the old TeamFoundationServer class.
Web Service changes
Most of the Web Services that TFS provides are not a documented or supported interface - however some tools still do use them.
The one that gets used fairly often is the Administration.asmx service with the QueryServerRequests() method that tells you which commands are currently executing on the server.
You should always use the supported object model or data warehouse & cube if it provides the information you need. See my blog post on How to query Work Items using SQL on the Relational Warehouse.
If you cannot use the object model, you will need to use the new URLs and regenerate your proxy classes.