Team System:team Foundation Server version control

At first, I did not want to open such a column, I began to brew this idea in February 2004. At the time, I was involved in a software design review of the upcoming product, code-named "Burton," at Microsoft headquarters in Redmond. At each review meeting, I raised my hand and asked the same question: "Is there an extension point?" "For two days, I always get a laughing answer:" Yes, Brian, you can customize it. "Burton is the later Visual Studio®team System, and how to customize it is everything in this column."

First, as with many columns, I'll give you an overview of how to extend and enhance the Visual Studio team System on both the client and server side. Next, I'll explain how to build a plug-in for Microsoft®word that allows you to check in the Word document and check out the team Foundation Server version control repository. Before you begin, however, visit msdn.microsoft.com/vstudio/extend to obtain a copy of the Visual Studio's? The SDK contains documents and samples that customize and extend the entire Visual Studio product line. In order to build this plug-in, you need a copy of Visual Studio Professional (or any role-based SKU that includes the team Suite), Visual Studio, and Tools for Office Second Ed Ition Beta and Visual Studio team Explorer. Since this column is primarily about extending team System, I'm not going to go into specifics about hooking code to the Word infrastructure, but provide all the code for your reference. If you need more information about writing Office Plug-ins, visit Msdn.microsoft.com/office/tool/vsto.

Delve into Team Foundation Server

Before you begin, you need to understand the core interaction between Team Foundation Server and the client plug-in or other related clients shown in Figure 1. If you want to use Team Foundation server, the first thing you need to do is connect to a valid server. To do this, you must know the server name, the protocol to use (HTTP or HTTPS), and the port. In order to perform version control operations, you need a workspace that contains a working folder. The workspace represents a client copy of a version-controlled project in team Foundation Server and can be used as an independent area for work. On a client computer, each user can have more than one workspace. Each workspace supports multiple mappings between a local file path (that is, a working folder) and a path in the version control repository. The Team Explorer tool uses your computer name to create a default workspace when you first use the source Control feature in Visual Studio 2005 with Team Foundation Server. This way, the plug-in needs to perform all of these operations so that the document can be put into the team Foundation Server version control repository or removed from it.

Figure 1 Checking the Word document into Team Foundation Server version control

Microsoft has distributed the APIs needed to implement team System programming in multiple assemblies. The core API set that the plug-in uses when interacting with team Foundation Server contains three assemblies that are installed as part of the installation of Team Explorer. respectively, Microsoft.TeamFoundation.Client.dll, Microsoft.TeamFoundation.VersionControl.Client.dll and Microsoft.TeamFoundation.VersionControl.Common.dll. The team Explorer installation application installs the assembly into the global Assembly cache (GAC). However, Setup does not register these assemblies so that they are displayed in the Add References dialog box in Visual Studio 2005. You will need to modify the Windows registry so that the Add References dialog box can display these assemblies (see SUPPORT.MICROSOFT.COM/KB/306149), or you can manually browse to locate the assemblies. You can find a copy of a browsable assembly at the%program files% \microsoft Visual Studio 8\common7\ide\privateassemblies\ location.