TFS to the rescue — almost
(Editor’s note: This is the first blog post by Christopher Yager, who will be writing on the .NET Developments blog from time to time. Yager is chief software architect at GLD Solutions Inc. and is currently using .NET 2.0 for his new development projects. Here he will blog about topics such as Windows Communication Foundation, Team Foundation Server and SQL Server. Welcome aboard, Chris!)
Before I get into this — welcome to my blog. I’ll be posting mainly about my adventures in .NET programming — feedback is welcome. I’m no guru but I did stay at a Holiday Inn Express last night. (Actually as I write I’m still at said Holiday Inn… )
So TFS (Team Foundation Server), Microsoft’s answer to the software lifecycle management problem, really is a great product. My team uses most features on a daily basis. My headline is somewhat misleading but allow me some latitude while I state my case. I run a software development company. We produce software products and we have customers that use them. (Go figure.) We have a QA staff. We test our products. TFS has no way to capture the guts of a user defined test against a product that tests a particular requirement. Specifically we needed to save metrics of test runs with success and failure rates, reasons for failure, environments tested, and lot of other neat stuff. I didn’t expect TFS to have all this rich user testing goo so I expected we’d roll our own. This article is about how we connected our hand-rolled testing metrics program with our Team Foundation Server.
The problem: A scenario test fails; a bug is created against a product/task/whatever and needs to be linked to the test that caused the problem.
The Solution: The TFS API!
Team Foundation Server has a plethora of components that you can leverage allowing seamless integration with the back end of your TFS implementation. These components are found in the following path normally:
[Program Files Root]\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies
**Client requirement: On any system you install your custom TFS linked software, Team Explorer must be installed. An obvious server requirement is that you have a Team Foundation Server installed somewhere in your network or available via the Web. If you’re interested in getting TFS running (and why wouldn’t you be?!) you can download a trial from Microsoft.
Our general requirement for this task was to view a list of active bugs for a team project and allow selection of one.
OK — some meat for you code monkeys.
Create a windows forms project in your favorite language. Mine is C# but any .NET language will do.
Add references to the following assemblies. You’ll need to browse for them since they are not in the GAC or otherwise registered for easy VS reference adding. The image shows them all together but this is a doctored image to save space.
Put a tab control on the form and set it to dock-fill (leave the 2 tab pages alone), size the form to 800X600 (this just saves us some time and coding).
We’re basically going to create two functions that perform the guts of the scenario. The GetWorkItems function which utilizes the DomainProjectPicker dialog class to allow the user to select the team project they wish to examine and the PickWorkItemsControl user control which allows searching of the TFS work item store.
private void GetWorkItems()
{
DomainProjectPicker dpp = new DomainProjectPicker();
DialogResult dr = dpp.ShowDialog(this);
if (dr == DialogResult.OK)
{
tfs = dpp.SelectedServer;
tfsProject = dpp.SelectedProjects[0];
this.Text = "My Team Foundation Link - " + tfsProject.Name;
Store = (WorkItemStore)tfs.GetService(typeof(WorkItemStore));
TeamProject = Store.Projects[tfsProject.Name];
pw = new PickWorkItemsControl(Store);
pw.Dock = DockStyle.Fill;
pw.PortfolioDisplayName = TeamProject.Name;
this.tabPage1.Controls.Add(pw);
pw.PickWorkItemsListViewDoubleClicked +=
new PickWorkItemsListViewDoubleClickedEventHandler(
pw_PickWorkItemsListViewDoubleClicked);
}
}
The InitWorkItemControl function allows the user to view the details of a selected work item and utilizes the WorkItemFormControl control.
private void InitWorkItemControl()
{
this.WorkItemControl = new WorkItemFormControl();
this.WorkItemControl.Dock = System.Windows.Forms.DockStyle.Fill;
this.WorkItemControl.FormDefinition = null;
this.WorkItemControl.Item = null;
this.WorkItemControl.LayoutTargetName = "WinForms";
this.WorkItemControl.Name = "WorkItemControl";
this.WorkItemControl.Size = new System.Drawing.Size(683, 428);
this.WorkItemControl.TabIndex = 0;
this.tabPage2.Controls.Add(this.WorkItemControl);
} We’ll tie this all together in the constructor for the form:
public Form1()
{
InitializeComponent();
InitWorkItemControl();
GetWorkItems();
}
Here is what the finished product looks like: (This is an out-of-the-box dialog, I didn’t write any of it.)
The search control on this form does not have any of my code in it. I only provided the tab control for it to live in.
The dialogs and controls exposed by the TFS API take care of the majority of the user interface, we just need to hook the stuff together with a little glue. You can download the sample solution which has both C# and VB .NET versions of the program.
Special thanks to Brian Randell who taught me this stuff through an article on MSDN Magazine.
Posted in VS 2005 and .NET 2.0, Visual Basic, C#, Architecture and the SDLC | No Comments »