Day 13: PowerShell and Team Foundation Server 2013 – Using the TFS API

Welcome to Day 13 of the “100 Days of DevOps with PowerShell”! For background on our goals in this series, see Announcing the “100 Days of Devops with PowerShell” Series here at SCC.

In my previous posts, I’ve shown what can be done using the PowerShell cmdlets that ship with the Team Foundation Server Power Tools. While the cmdlets provide some functionality for working with TFS, that functionality is not extensive. To really get in depth, you have to start using the TFS API. In this post, I’m going to create the same work item that I did in my previous post, only this time I will use the TFS API.

Here is the final script:

Let’s break it down.

I start off, as before, by loading the TFS PowerShell snap-in, if it is not already loaded. Then I load the TFS API assemblies that I need for my script. You can find all the different assemblies, for different versions of the .NET Framework, at C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies.

To work with the work item tracking system, I need to first connect to the appropriate Team Project Collection. In my script I am creating my Team Project Collection object by passing in the URL of my Team Project Collection to the GetTeamProjectCollection method of the built-in factory class. This is the easiest way to do this. I could instead add code that opens the TFS Project dialog box, allowing me to select the collection using a GUI.

To create a new work item, I need to access the Work Item Store. The Work Item Store can be used to access queries, create queries, create work items, and edit work items.  Once I have that object, I can then get a reference to the Team Project where I want to create the new work item.

To create the new work item, I need to first get a reference to the Work Item Type that I want to create, in this case a Task work item type. With that, I can use the NewWorkItem() method to create a new Task work item object.

Finally, with the reference to the Task work item, I can set the properties of the work item, and then call the Save() method to save my changes.

TIP: The PowerShell ISE makes working with the TFS API very easy, as it provides full IntelliSense options.

The TFS API should be used for any detailed or complicated PowerShell scripting against Team Foundation Server. It gives the most flexibility. In future posts I’ll show how I use PowerShell and the TFS API to help integrate other System Center products. Up next from me, though, we will start diving into the IT Pro / Service Desk side of DevOps, with a look at PowerShell and System Center Service Manager 2012.

2 thoughts on “Day 13: PowerShell and Team Foundation Server 2013 – Using the TFS API

  1. Dalmiro

    Hello! First of all let me thank for this series. Its looking great so far.

    1) Why is the TFS snap-in being loaded? No commands from that snap in are being used on this script.

    2) Getting the following error when reaching to $workitem.save

    Exception calling "Save" with "0" argument(s): "TF237124: Work Item is not ready to

    save"
    At line:38 char:1
    + $workItem.Save()
    + ~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ValidationException

    Thx!

  2. R Aravamudan

    I face issues with LoadWithPartialName

    GAC Version Location
    — ——- ——–
    True v2.0.50727 C:\Windows\assembly\GAC_32\Microsoft.TeamFoundation.Client\9.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.Client.dll
    True v2.0.50727 C:\Windows\assembly\GAC_32\Microsoft.TeamFoundation.WorkItemTracking.Client\9.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.WorkItemTracking.Client.dll
    True v2.0.50727 C:\Windows\assembly\GAC_32\Microsoft.TeamFoundation.Build.Client\9.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.Build.Client.dll
    True v2.0.50727 C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.WorkItemTracking.Client\10.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.WorkItemTracking.Client.dll
    True v2.0.50727 C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.WorkItemTracking.Client\10.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.WorkItemTracking.Client.dll
    True v2.0.50727 C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.Client\11.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.Client.dll
    True v2.0.50727 C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.WorkItemTracking.Client\11.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.WorkItemTracking.Client.dll
    True v2.0.50727

    C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.Build.Client\11.0.0.0__b03f5f7f11d50a3a\Microsoft.TeamFoundation.Build.Client.dll

     

    The last three were loaded with the following code

     

    [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.TeamFoundation.Client”)
    [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.TeamFoundation.WorkItemTracking.Client”)
    [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.TeamFoundation.Build.Client”)

     

    The first were loaded with the following

    $assemblyPath1 = “D:\DLLS80\Microsoft.TeamFoundation.Client.dll”
    $fullName = [System.Reflection.AssemblyName]::GetAssemblyName($assemblyPath1).FullName
    [System.Reflection.Assembly]::Load($fullName)

     

    I am able to retrieve work item ids only with LoadWithPartialName (v 9.0.0.0) in a separate system, whereas in my system the GAC is loaded with multiple versions and LoadWithPartialName, and returns 11.0.0.0 only.

    The other load methods do not return work items (returns null value) . How do I force LoadWithPartialName to pick up 9.0.0.0 ?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.