Foo Theory

Introduction

A large number of developers are using Team Foundation Server for a variety of tasks such as Source Control, Bug Tracking, Requirements gathering, running nightly builds and managing the overall life cycle of a software development project.

Visual Studio Team System provides rich integration with Team Foundation Server through Team Explorer, which provides the basic connectivity to TFS. Users can use Source Control Management to manage their source code, manage Work Items, create Build types, run Unit Tests and Load Tests, run one of many SQL Server 2005 Reporting Services-based Team Reports etc.

In addition to Visual Studio, Office 2003 and Office 2007 also offer direct or indirect connectivity to Team Foundation Server. You can have Work Items show up as Tasks in Outlook 2007, you can export a Microsoft Project 2003 schedule to TFS, creating Work Items in the process, or you can export and import your Work Items to and from Excel 2007.

Even if you are working outside of the realm of the  .NET and the Microsoft development platform, you can use the TeamPrise plug-in for Eclipse to provide connectivity from your favorite Java development environment to Team Foundation Server.

What a lot of people don't realize is that Team Foundation Server also offers a powerful development object model, empowering the developer to create custom development tools, specialized clients, custom WebParts for a Team Project SharePoint portal and so on. Team Foundation Server was developed from the ground up with extensibility in mind. Indeed, TFS itself is build upon the Team Foundation Core Services, which are a set of Web Services used by Team Foundation Server itself to implement the different functional areas for Team Foundation Server.

As a developer, you will seldom have a reason to directly use the Team Foundation Core services. Indeed, Microsoft created the Team Foundation Server Object Model to increase the productivity of the TFS developer. The classes in this object model interact with the Web Services of the Team Foundation Server Core Services and make it easy for you to extend the functionality of Team Foundation Server in one of the following ways:

1. Create a custom TFS command-line tool.
2. Develop custom PowerShell cmdlets or PowerShell PSDrive providers that allow you to directly navigate the TFS repository.
3. Develop a SmartClient or Web client for Team Foundation Server.
4. Develop a custom check-on policy for your development team
5. Create a  plug-in for a third-party development tool.
6. Create a custom SharePoint WebPart for your Team Project SharePoint portal.
7. Implement custom Contiguous Integration (CI) tools.
8. Create new Team Foundation build tasks.

In article two of this series we will create a custom class library, which will directly interface with the Team Foundation Object Model. We will create a set of Units Tests for the classes and methods in this library, and we will create a simple console client to navigate the object model.

In part two of this article series, we will create a custom PowerShell PSDrive provider for TFS. This provider will allow us to navigate through the different artifacts in the TFS database, as if they were files and directories in the file system. We will be able to use the standard dir, cd, type etc. alias commands, together with the standard Get-ChildItem, Set-Location, Get-Content, etc..  PowerShell cmdlets to navigate the TFS structure. The implementation of this provider will leverage the class library that we create in this post.

In the final post of this series, we will build a custom WPF client for Team Foundation Server, which will allow us to browse, edit and create Team Projects and Work Items. In the course of implementing this client, we will have an opportunity to dive into some interesting WPF features, such as data binding, data templates and control templates. We will also leverage the TFS eventing service to keep our UI synchronized with the TFS repository at all times.

Extensibility versus Customization

Before we dive into the details of the TFS extensibility model, I would like to clarify some terms that tend to lead to confusion in the community. These terms are:

1. Customization. Customization involves modifying your environment, such as Visual Studio Team System or Team Foundation Sever, using the tools that are provided to you by that environment. It is important to note that there is no real coding involved in customization. Indeed, before you go fire up Visual Studio to write custom code to perform a certain task, I would encourage you to check out the Team Foundation Administrator's Guide in the Team Foundation Help documentation. In a lot of cases, you will notice that you can customize your TFS environment by using the existing toolset, or by simply modifying one or more of XML files. Also, I would encourage you to download the Team Foundation Server Power Toys, which extend the reach of the existing TFS toolset even further. Customization might include:
   • Modifying a Process Template.
   • Creating a new Work Item Type.
   • Customizing Team Foundation Build.
   • Modifying the Project Portal Template
   • Turning check-in policies on or off.
2. Extensibility. Extensibility is concerned with adding new functionality to your environment, which typically does involve coding. You can extend a Team Foundation Server installation by writing code to access the Team Foundation Server object model. This way you can build add-ins and integration components that round out the Team Foundation Server product line. TFS Extensions are typically created by internal IT departments or third-party independent software vendors (ISV's). Some extensibility examples are:
   • An adapter that integrates an existing toolset with Team Foundation Server. A good example is the TeamPrise plug-in for the Java Eclipse development environment.
   • A Customized Team Foundation Server development solution for a vertical industry (for example Healthcare-specific process templates, new Work Item Types with Healthcare-specific workflows etc.).
   • Custom explorer clients (like the one we will be developing in part II of this series).

Our focus of this series is on extensibility. I do have some ideas for future posts on TFS customization, so make sure you subscribe to our RSS feed!

The Team Foundation Core Services

The Team Foundation Core Services (TFCS) are a set of services running on the Application Tier of TFS, which allow us to access the different aspects of Team Foundation Server, including administration, security and events. TFCS enable customers and Microsoft Partners to extend Team Foundation functionality by developing Team System extensions and adapters to integrate third-party tools with Team System.

TFCS is made up our of five services:

1. Classification Service. This service provides access to Team Project information, and the different structures that make up a Team Project. In this article, we will mainly be focusing on this service.
2. Eventing Service. The Eventing Service allows Team Foundation Servers to communicate by raising events and listening for events. This is how tools like CruiseControl.Net are able to kick of a build in response to a check in. They use the Eventing Service to listen for these events, and react appropriately. We will use the Eventing service in our custom WCF client, to keep our displayed information synchronized with the TFS repository at all times.
3. Linking Service. This service provides the ability to link items together, such as Work Items and files that are version controlled. One interesting aspect of the Linking Service is that you can create a link between two artifacts that were created by different tools which have no knowledge of each other. This type of loose coupling is achieved by assigning Uri to each artifact in the TFS repository, and creating links between these Uri's.
4. Registration Service. The Registration Service allows a TFS component to discover other services registered on Team Foundation Server. Therefore, when you create a new TFS service, it should be registered on the service by using the Registration Service, so that it can be found and utilized by the other server components. You can compare the Registration Service to a UDDI registry for Web Services.
5. Security Service. The security service implements a unified security model used by Team Foundation Server to manage users, groups and permissions. If you create a custom TFS component, you have the ability to integrate your extension into this security model, and have your artifacts behave correctly within the TFS security model.

The above services are implemented as Web Services. Team Explorer and the different components of Team Foundation use the above services to implement their functionality. As I mentioned before, you will not often have a reason to call these web services directly. Instead, you will use  the Team Foundation Object Model to interact with these Core Services. This is what we will do to implement our Console, WCF and PowerShell clients.

An overview diagram is shown below:

In the next sections, we will take a more detailed look at the Classification Service. Future articles will take a look at the other services within the context of the overall article.

The Classification Service

 The classification service provides access to Team Project information, including the Team Project name and the Uri, as well as access to the areas and iterations of the project. The Area and Iterations sections of a Team Project form the structure of the project. This service allows you to view project information, and make changes to a project's structure. An example of using this service would be to populate the top nodes of a tree view that looks like the main tree view of team explorer, showing the names of all of the Team Projects on the server. From these nodes you could then use other services to create the other nodes in the tree (such as accessing the Work Items that belong to a Team Project, which is what we will be doing in our custom WCF client).

Some example of the services offered up by the Classification Servers are listed below:

• Creating a new Team Project.
• Delete an existing Team Project.
• Access the properties (name, Uri, process template Id and Project properties) of the Team Project.

The common pattern for accessing the object model is to first establish a connection to the server Once you have a connection to the server, you can query the server for the type of interface you would like to use. This model is not unlike the WF Runtime Model, where you can ask the Workflow Runtime for the different services, such as the persistence or threading service.

To access the Classificiation service, you query the server for the ICommonStructureService type, defined in the Microsoft.TeamFoundation.Server namespace in the Microsoft.TeamFoundation.Server.dll assembly.

In my next post, we will dive head-first into the Classification service, and the TeamFoundationServer object, which is at the root of the Team Foundation Object Model hierarchy.