David Truxall

I got error TF31002 when trying to connect to TFS 2010 with Visual Studio 2008:

The basic problem is that in Team Explorer, before Visual Studio Service Pack 1, you can’t enter a valid URL in the Add Team Foundation Server dialog, only a server name or IP address. Unfortunately TFS 2010 changed the URL of the server to this format: http://<servername>:<port>/tfs/, adding a virtual directory that TFS 2008 does not have. Pre sp1 this syntax is not allowed in the dialog box. Just putting in the server name produces the above error, which, in the irritating way that error messages work, is completely correct since the services can’t be found because they now reside in a virtual directory.

To get Visual Studio 2008 to connect to Team Foundation Server 2010, there are definitely some steps you need to follow. I found a bunch of mostly correct information, but nothing exactly right (beta and RC were widely available) so I figured I’d post it here.

To begin with, you need to install the following, in this order to Visual Studio 2008:

1. Team Explorer for TFS
2. Visual Studio 2008 sp1
3. Visual Studio Team System 2008 Service Pack 1 Forward Compatibility Update for Team Foundation Server 2010

If you already installed Service Pack 1 and need install Team Explorer, you will need to re-apply the service pack.

Enter the URL like this:

http://<servername>:<port>/tfs/

Now you should be good to connect to the server.

Wriju has a gread roundup of eBooks/guidance available on CodePlex.

Microsoft Content Management Server (MCMS) and Team Foundation Server (TFS) in Visual Studio 2005 don’t play nice together. Since MCMS is a dead-end product, I don’t expect there will be an actual fix.

The KB Article fix (sort of).

Stefan’s workaround. Essentially you need to use them separately, TFS with Visual Studio and a standalone version of the MCMS Template Explorer.

1. Work on a dummy TFS project that you can delete. Delete the project before you deploy for production.
2. Not all the attributes for Work Item layout are documented.  
3. A Work Item Type defined in more than one project is sort of shared between the two. The definition can be different, but the name is shared. So anything you want to change or remove in one has to be done in the other. See item 1.
4. Work items are not easy to delete. It can only be done through the database. See the SQL statements for doing removing work items. I found a GUI tool for this, but ultimately it was executing the SQL statements.
5. Work Item Type fields are not easy to modify. Essentially you have to delete it and re-add it. The basic steps are:
   1. Remove the field(s) from the Work Item Type XML definition (both field and in the layout)
   2. Re-import the Work Item Type XML so the definition in use no longer contains the field(s)
   3. Delete the fields using the TFS command line tools. This also deletes any data you had stored for existing work items using your custom type.
   4. Re-process the cube using the TFS web service
   5. Update the Work Item XML with the updates you need
   6. Re-import the Work Item Type XML

Of course, after-the-fact I found a good overview of the custom Work Item process.