Category: Team Foundation Server

TFS: Execute Query and Return a List of Work Items

You’ll need to use NuGet to install the Microsoft.TeamFoundationServer.ExtendedClient library before anything:

Then the following code:

Line 17 sets up the VssConnection which is used for multiple comman.  Line 18 sets up the WorkItemTrackingClient (witClient).  Line 20 retrieves the folder hierarchy; line 21 picks out the folder we specified.  Line 22 sets up the returnValue for the procedure.

After that processing is fairly linear.  We execute the query (and throw an exception if there’s no results).  We pull down batchSize number of work items each time through the loop.  Skip is used to track how many we’ve already snagged and should bypass on the next loop through.

Next up:  pulling changesets based on their relationship to work items.

Team Foundation Server: Change Default Behavior on Checkin From Resolve to Associate

The default behavior on checkin with TFS 2010, 2012, 2013, and 2015 is to close the associated work item.  If you’re checking in on a daily basis, this is annoying.  To change it for the current client, you need to change a registry key.

To make Associate the default action instead of Resolve set:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\<version>\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction to False.

Replace <version> in the above registry key with the appropriate Visual Studio version below.

Visual Studio 2010:  10.0
Visual Studio 2012:  11.0
Visual Studio 2013:  12.0
Visual Studio 2015:  14.0

Microsoft promised to make this a non registry change some time ago, but as of 2015 I still don’t see this as an option.

Team Foundation Server 2015: Connecting to a Repository and List Collections

Previous Posts:
Team Foundation Server 2015: Integration and Extension

You can find an architectural overview of Team Foundation Server on MSDN if you’re curious.  I personally find that the architecture and object model don’t correlate clearly, so we’re going to create our own diagram.

At this point in my desire to understand the programmatic model, Team Foundation Server consists of Collections, Projects, Branches, Work Items, and Change Sets.  There’s far more than that available, of course.


The first class of interest to us is TfsConfigurationServer (Microsoft.TeamFoundation.Client namspace, Microsoft.TeamFoundation.Client.dll, v14.0.0.0 assembly).  There are two ways to retrieve an object of this class.  First, use the constructor with a Uri object.

Second, use the TfsConfigurationServerFactory (Microsoft.TeamFoundation.Client namespace, Microsoft.TeamFoundation.Client.dll, v14.0.0.0 assembly) to retrieve an instance of the class:

The difference between the two is that the factory will cache the object for you; subsequent calls to it with the same URI will result in the same object being returned to your code.

Now we’re connected, although authentication doesn’t happen until you make a call against the object (use TfsConfigurationServer.EnsureAuthenticated() if you want to verify this prior to processing).  How do we list the collections held by this TFS instance?

If you look at the MSDN definition for TfsConfigurationServer, there doesn’t appear to be any methods which will return collection information.  The data we’re looking for is actually held by a property, CatalogNode (Microsoft.TeamFoundation.Framework.Client namespace, Microsoft.TeamFoundation.Framework.Client.dll, v14.0.0.0 assembly).

The CatalogNode property is Microsoft’s method of abstracting away the differences between objects held within the TFS object hierarchy.  Each CatalogNode has a CatalogResource (Microsoft.TeamFoundation.Framework.Client namespace, Microsoft.TeamFoundation.Framework.Client.dll, v14.0.0.0 assembly) associated with it.  This CatalogResource represents the actual catalog item.  The CatalogNode is used to store relationship data.

Off of the CatalogNode property we’ll find a QueryChildren method.  This is what we use to find the objects that we want.  There are two overloads to the method; we’ll cover QueryChildren(IEnumerable<Guid>, bool, CatalogQueryOptions).  The second overload I’ve been unable to find a sample for, and am unsure how to provide arguments to.

The first argument to QueryChildren represents the CatalogResourceTypes (Microsoft.TeamFoundation.Framework.Common, Microsoft.TeamFoundation.Framework.Common.dll, v14.0.0.0 assembly) you want to have returned.  It’s an array of Guids because it is not an enumeration; the values used represent static values on the CatalogResourceTypes class.  You’ll most often see the array created inline with the function call.

The second argument to QueryChildren indicates whether or not you want the search algorithm to search recursively for the object types you’ve indicated.  While this makes little sense for an enumeration of collections, you’ll find the catalog used throughout the API – recursively searching for work items makes more sense.

The final argument to QueryChildren is a CatalogQueryOptions enumerated flags value (Microsoft.TeamFoundation.Framework.Common, Microsoft.TeamFoundation.Framework.Common.dll, v14.0.0.0 assembly) indicates whether you want additional data prepopulated on the result set.  There are three options:  ExpandDependencies, IncludeParents, and none.

A final note on the return value of QueryChildren.  ReadOnlyCollection is a generic based collection found in System.Collections.ObjectModel.  Why is it in System.Collections.ObjectModel?  See here.

Once we have the results from the server we use the Resource property on the CatalogNode to access the object data we want.

Complete listing: