Team Foundation Server (TFS) Work Items – how to get to your Work Items

Previously we discussed getting a collection of Changes from your TFS server based on path. This was pretty straight forward and only involved working directly with the TFS version control store. I would call this “a developer view”.

Now, let’s take a look at things from the project manager perspective. A PM wants to know what happened to his/her TFS work items. Conveniently enough TFS obliges by providing the WorkItemStore object. It’s easy enough to load up in your Powershell shell:

#enter a path to your tfs server
$tfsServer="http://DefaultServer:8080/tfs"

# get an instance of TfsTeamProjectCollection
$tfs=get-tfsserver $tfsServer

# get an instance of WorkItemStore
$WIT = $tfs.GetService([Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore])

Note that for this to work properly, you have to have Microsoft.TeamFoundation.WorkItemTracking.Client asembly loaded. Check out Zhenhua Yao’s article for a nice overview of which assemblies need to be loaded and in what case.

Now you’re armed and dangerous, but don’t have the work items yet. You can get them in two ways:

• GetWorkItem method – an overloaded method that allows six different ways to ask for a given WI
• Query method – an overloaded method that allows six different ways to run a WIQL query

GetWorkItem method – There are three factors that be used in identifying a work item through this method:

• Work Item Id – int32 identifier. This is simply the WI number. Easy to get and to use.
• Uniform Resource Identifier (URI) – Granted, this is not the most useful way to access a WI, but sometimes it could come in handy.
• Version Date or Revision ID – This option is rather interesting, it can be used in conjuction with WI number or URI to get an older revision of a WI. But, to be honest, I have yet to find a use case for this overload option, especially considering that revision collection allows us to browse all of WI history. If you have a good use case for it, please let me know.

Here is an example of a GetWorkItem(Int32) method:

$WIT.GetWorkItem(1234)

doesn’t get much simpler, does it? It returns a fully stocked Work Item Object. In the next post we will discuss how to use it.

Query method – as if we didn’t have enough query languages, here is another one – Work Item Query Language (WIQL). Microsoft tries hard to explain the syntax in plain English, and also offers an Extended Backus Naur Form (EBNF) version. However, there is enough ambiguity in MS documentation to make getting started challenging and mysterious. I will cover it in more detail in an upcoming post, so don’t want to spend too much time on it complexities. For now, let us just note that this method will return a collection of Work Item Objects. So, for example, we want to see all WI that were resolved by the superman. Easy enough:

#create a query string
$str="select * from WorkItems where [Microsoft.VSTS.Common.ResolvedBy] Contains 'superman'"

#execute the query
$WIT.Query($str)

#print out WI titles
 $WIT.Query($str) | %{$_.Title}

As you can see, you get a colelction of WI Objects ready for iteration with the simple “For Each” (shorthand – %) operator. In the next installment, we will take a short detour to explore WIQL and after that will come back to see what can be done with the WI object and how can we use it to get to actual changes that are associated with it.