Jump to content
Software FX Community

Connecting gadgets to Team System


Recommended Posts

Given the fact that we use Team System to manage the PowerGadgets development process, it was only obvious that we would test our gadgets by connecting to the work item store and display our project information in the Vista sidebar or desktop. Although PowerGadgets is primarily targeted to IT professionals and DB administrators, we hope other developers may find this post useful.

Although there are several blog posts with scripts talking directly to the TFS API, we chose to develop a cmdlet as it is more portable than a collection of scripts and although the cmdlet code is relatively simple, debugging a cmdlet is easier than debugging a script.

To install this snapin simply unzip the files to any folder in your machine and run InstallUtil passing the path to PowerGadgets.TFSCmdlet.dll as a parameter. InstallUtils is located in the .NET Framework folder which is typically at C:\Windows\Microsoft.NET\Framework\v2.0.50727. This snapin does not depends on any PowerGadgets assemblies so you can use it even if you do not have PowerGadgets installed in your machine.

This is probably the main cmdlet in our snapin and it returns a collection of work items, it supports the following parameters:

Server: Server name hosting the TFS Web Services, e.g. tfserver.company.com
Port: Port used by TFS Web Services (defaults to 8080)
Project: Project Name or All (defaults to All)
Type: Bug, Task, ... or All (defaults to Bug)
State: Active, Resolved, ... or All (defaults to Active)
CreatedBy: User Name, me or All (defaults to All, more on how User names are handled later)
Priority: Priority number or -1 for all priorities (defaults to -1)
Reason: Fixed, New ... or All (defaults to All) 
AssignedTo: User Name, me or All (defaults to @me, more on how User names are handled later)

The first 3 parameters are supported in all our TFS cmdlets and can be set in a config file located in the same folder as our snapin, there is a lot of information in the TFS store but we chose to return the following work item info: ID, Title, Type, State, Reason, Priority, CreatedBy, CreatedDate, ResolvedBy, ResolvedDate, AssignedTo, Project and Description.

Note that most of the parameters are used to filter the number of work items returned by the TFS web service to the cmdlet, you can also filter using the where cmdlet but this will result in more information sent from the server. This is similar to filtering at the WMI level against piping get-wmiobject cmdlet to a where cmdlet.

Returns a collection of change sets and it supports the following parameters

From: Specifies the starting date for which to return changesets
LastBuild: A switch parameter that allows you to see the changesets since the last build
Owner: User Name to filter the changesets.

This cmdlet returns the following changeset info: ID, Comment, Owner, Date and the associated Work Items.

Returns a list of builds for the specified project, we couldn't find a way to limit the output of the native TFS web service so no extra parameters are supported, you can always use the where parameter to get a subset.

This cmdlet returns the following build info: BuildMachine, DropLocation, BuildStatus, StartTime, BuildType, RequestedBy, TeamProject, BuildNumber, BuildQuality, BuildUri, FinishTime, LogLocation, LastChangedBy, LastChangedOn and BuildStatusId

We wrote this cmdlet because we currently use a homegrown build and test system and we chose not to migrate to Team Build yet. As part of our build process we want to send emails to interested parties (PM, testers, etc.) as soon as a build is finished letting them know which work items were associated with the build including changesets comments.

This is an in-progress cmdlet that talks to the TFS Warehouse instead of using the web services. The idea is that this cmdlet will contain a prebuilt number of MDX statements and will also you to run your own. If the MDX returns 1 or dimensions you can output those to the console (or to a chart) but when returning more than 2 dimensions something else is needed. We have modified our out-chart cmdlet to understand OLAP cubes and it allows you to slice and dice from all the dimensions in the MDX. This code is still in a very early stage and it is being done in our development branch. If somebody is interested in exploring OLAP (TFS or any other cube) in a gadget we can make a pre-release version available. We will write a blog post including some OLAP gadget screenshots in the following weeks.

With this cmdlets we have used several gadgets internally including the following, note that this assumes you modified the config file and selected a default server:

  • A radial gauge showing the number of total active workitems/bugs/tasks in a specific project

get-workitem -project PowerGadgets -type All | measure-object | out-gauge -type radial

  • A chart showing the number of total active workitems grouped by type assigned to me

get-workitem -project PowerGadgets -type All -assignedto me | group Type | select Count,Name | out-chart

  • A digital panel displaying the number of open bugs assigned to me

get-workitem -project PowerGadgets -assignedto me | measure-object | out-gauge

  • A gauge showing the revision (3rd number in the version which normally identifies the day) for the last build

(get-build -project PowerGadgets| select -last 1).BuildNumber.Split('.')[2] | out-gauge

  • A line chart displaying the number of workitems resolved by day

get-workitem -project PowerGadgets -state Resolved | select @{Expression={$_.ResolvedDate.Date};Name="Date"},Id | group Date | select Name,Count | out-chart -gallery lines

This gadget is aggregating by date using $_.ResolvedDate.Date and is also doing an extra select before piping to out-chart, this is because out-chart has a built-in functionality where double clicking on a group shows details for the groups but in this case double click was not required.

  • A gauge showing the number of work items created by me fixed the last 30 days

get-workitem -project PowerGadgets -state Resolved -createdby me | where {([datetime]::now-$_.resolveddate).TotalDays -lt 30} | measure-object

About user name handling: TFS seems to use 3 different name conventions, some APIs will return the login name (e.g. JonhS), others will return a domain qualified name (e.g. YOURCOMPANY\JohnS) and yet others will return a full name (e.g. John Smith). Because of this we tried to standardize on using the login name and the config file allows you to specify the conversion between login name and full name.

About PG creator: If you want to create a gadget using one or more cmdlets in this snapin you can do so, note that you will select PowerShell as the data source and you have to press the snapins button in the PowerShell configuration wizard to add the snapin.

About 64bits: the .NET assemblies that implement the connection to the TFS web services are marked as x86, this means that if you want to create some of these gadgets in a 64bits machine you will have to run the x86 PowerShell. This also means that it is not possible to host these gadgets in a 64bits machine sidebar as this process is always a 64bits process. If you need help setting this up please let us know.


Link to comment
Share on other sites

  • Create New...