I like Virtual PC and I use it a lot. Recently I decided to rebuild my set of VSTS and TFS images. So I happily created a base image with Windows 2003 Server R2, IIS and Office 2007. This will serve as a good base for the rest of my disks, I thought. Next, I copied the base image to install TFS 2005 on it. I started up the VPC, used NewSID to change the computer Sid and give it a new name. Then I installed TFS and all its prerequisites without any problems. Patched it with service pack 1. Tested according to the doc’s (ran the web service, viewed the report site etc). All is good.

Then I went ahead and created a team project in TFS. Not so good… The project wizard failed with this error when creating the Share Point site:

Error
Unable to connect to the Windows SharePoint Services at TFSDEMO01 

Explanation
The Project Creation Wizard was not able to connect to the Windows SharePoint Services at TFSDEMO01. The reason for the failed connection cannot be determined at this time. Because the connection failed, the wizard was not able to complete creating the Windows SharePoint Services site. 

The project creation log didn’t say much more. The most interesting was the statement before it failed where it verified that the Share Point templates existed (http://tfsdemo01/_vti_bin/Sites.asmx).

Finally, this was logged to the Windows event log:

#50070: Unable to connect to the database STS_Config_TFS on TFSDEMO01.  Check the database connection information and make sure that the database server is running.

Since the errors were unintuitive, I Googled a while, checked permissions, updated the IIS scriptmaps, and checked a good number of other things to find the cause for the error. Nothing. Until I came across this post and it dawned on me. Never install IIS on a VPC image, then change the computer name (or Sid?) and expect IIS to work correctly after. This is probably obvious to everyone... What really fooled me was that IIS responded correctly and the TFS setup went through without an error.

Yesterday, a colleague of mine told me how I could enable hardware virtualization for Virtual PC on my Dell laptop (just enable it in BIOS). Now life is good again.

Microsoft patterns & practices team just released the final 1.0 version of the Team Development with TFS Guide. This PDF book contains lots of useful guides and best-practices, ranging from source code control to build automation to process customization to... Get it here.

Buck Hodges has announced the release of the the Microsoft branded web front-end to Team Foundation Server based on DevBiz Team Plain (which was aquired by Microsoft earlier this year). Brian Harry has written a long post about the history of the product and about the features of this release.

I downloaded the distribution from here and the uninstalled the version of DevBiz Team Plain (2.0 RC) I had installed already. Running the setup after that went fine and after less than 5 minutes total the Visual Studio Team System Web Access was up and running. So far I've seen little differences from the Team Plain version but than again most of the features were already in Team Plain 2.0.

Buck Hodges just announced the date for the next Team System chat. These chats are very informative with a lot of really interesting questions raised by people in the VSTS community.

Finally Peter Blomqvist and I have managed to released a first beta of our pet-project TFSBuildLab. I wonder why it's so hard to actually get working software out the door... Anyway, TFSBuildLab is a Team Foundation Server add-on that enbles continuous integration and build automation similar to the what we're getting in TFS "Orcas". We've developed the tool as a shared project on CodePlex and used it in our common development project since april this year. Peter has a detailed post with nice statistics from the project where we've used TFSBuildLab.

Comments and suggestions are appreciated - please post to the CodePlex forum where we can have an aggregated view of ideas.

As most users of TFS have become aware of, it is not possible to directly create a screenshot in a TFS Work Item. This is particularly awkward when working with bugs in TFS, since commonly a key part of a bug report is to include a screen-dump of the issue at hand. There are a few attempts to solve this problem (Automatically raise bugs from IE, Snag-it output for TFS) but none I’ve seen addresses the problem that you actually want to do the capture from the work item itself.

So having thought about this for a while I decided to write a TFS Work Item Custom Control that can create new attachments to a work item based on an image available on the Windows Clipboard. So the scenario for the user of the control is to find the window to attach to a work item and then press “print screen” for the entire desktop or “alt-gr print screen” to capture a specific window. The content of the clipboard will then be saved as an attachment. Simple enough was my idea.

The code for the Work Item Screenshot Control can be downloaded here: TFSScreenshotControl.zip (26,39 KB)

There is very little documentation available on how to develop custom controls for TFS work item tracking. The references I’ve found must useful are these:

·         http://msdn2.microsoft.com/en-us/library/bb286959(vs.80).aspx

·         http://blogs.msdn.com/narend/archive/2006/10/02/How-to-use-Custom-Controls-in-Work-Item-Form.aspx

·         http://www.codeplex.com/WitCustomControls

When it comes to debugging WIT custom controls, I can only say that it works pretty well be attaching one Visual Studio instance with the control project loaded to another running the Team Explorer and the work item to test. The most annoying thing is that the VS instance having opened a work item form with the custom control on it will lock the control file so in order to test an updated version Visual Studio must be restarted.

The Capture control can be added to any work item tracking type definition. Typically you would provide a label and then the Capture button, similar to the following image:

And here’s a cool feature – if the clipboard doesn’t contain an image then the Capture button is disabled. It will become enable as soon as the user presses “print screen” or “alt-gr print-screen”.

When the button is pressed a “Save As Attachment” dialog is shown. The dialog lets the user enter the attachment name and comment as usual. Pressing OK will create a new attachment to the work item.

It is also possible to click on the preview image to bring up a larger window with the screen shot:

To make the capture control even more useful, I’ve also implemented an alternative “File Attachment” control. This control works just like the standard control but also provides the Capture feature.

To use the control first create a work item type that contains the image. In essence the only thing that needs to be done is to include a new control in the <FORM> section in the work item XML. The following examples shows the syntax for the ScreenShot control and the FileAttachment control respectively:

<Control Type="ScreenshotControl" Label="Screenshot:" LabelPosition="Left" />

<Tab Label="File Attachments">

   <Control Type="AttachmentsControl2" LabelPosition="Top" />

</Tab>

After that the control and its associated .wicc files need to be deployed locally on each machine using the control (and no, the TFS web client will currently not handle custom controls). Team Explorer searches for custom controls in folder “Microsoft\Team Foundation\Work Item Tracking\Custom Controls” under Environment.SpecialFolder.CommonApplicationData folder first, then under Environment.SpecialFolder.LocalApplicationData.

So, that was it. Hopefully these little controls will fill part of the gap when it comes to handling screenshots in TFS work items.

Lately I’ve been doing a fair bit of programming against the TFS. For most parts it’s been a good experience, what I’ve found most frustrating is the lack of good documentation. So in this post I’ve collected the links I’ve found most useful when developing against the TFS.

The functionality in the TFS can generally be accessed either directly through the web services in the application tier or through the TFS client-side object model. Always use the TFS object model. It may be tempting to use the other ways to alter the TFS but the API is intended to shield the application you write from eventual changes in the web service layer.

Buck Hodges has a number of code samples on his blog (many won’t run on the RTM version but will still serve as good examples). In particular this post has a set of links to other code samples.

These links to MSDN-online are good starting points with both general information and source code:

·         How to: Use the TFS SDK to Write Code

·         Work Item Tracking Extensibility

·         Source Control Extensibility

For the best set of samples and documentation, download the Visual Studio 2005 SDK. The SDK contains various samples on how to use TFS, work items, source code control, check-in policies. The Visual Studio Industry Partners, VSIP, program has even more content on how to extend the Visual Studio suite including Team Foundation Server. VSIP requires registration but is free for the basic level of participation.

Buck Hodges has a post on “How to add the Team Foundation assemblies to the .NET tab in the VS Add Reference dialog”. Having the assemblies available in the "Add reference" dialog will save some time and confusion each time you want to access the TFS object model so it's definately something to setup. On that subject it is recommended to reference the Team Foundation Server assemblies from the SDK (%install path%\VisualStudioIntegration\Common\Assemblies\) instead of using the ones in Visual Studio private assemblies or on the TFS server.

These blogs also has a lot of good code samples to use as reference:

·         Merrick Chaffer

·         Jeff Attwood 

And finally, look at CodePlex, there are a lot of TFS applications being written as open-source projects and the code can always be downloaded and used as a source of information.

As a follow-up to the last post on how to use BisSubscribe.exe for setting up email notifications on work item changes, here’s a sample on how to use BisSubscribe to generate an email whenever someone does a check-in and overrides a check-in policy:

BisSubscribe.exe /eventType CheckinEvent /address mathias@win2003 /deliveryType EmailHtml /filter "PolicyOverrideComment <>''" /server http://localhost:8080

Whenever a user checks-in code and does a policy override a mail like the one below is sent:

A common issue when working with Team Foundation Server and work items is how changes in a work item can be notified to a user using standard email.

By using the BisSubscribe.exe tool (discussed in the previous post) we can use a command-line utility that adds subscribers to the TFS notification database. The tool can be used for setting up email notifications as well as notifications to a generic web service for application level integration. In this scenario we’ll use the email option.

So to register for a notification when a work item’s status changes we’ll use this command:

BisSubscribe.exe /eventType WorkItemChangedEvent /deliveryType EmailHtml /server http://localhost:8080 /address mathias@win2003 /filter """"PortfolioProject""" = 'Effective VSTS' AND ("""ChangedFields/StringFields/Field[ReferenceName='System.State']/OldValue""" <> """ChangedFields/StringFields/Field[ReferenceName='System.State']/NewValue""")"

Whenever someone changes the status of a work item TFS will produce a mail similar to the following:

TFS comes with a tool called bissubscribe.exe, typically installed at “C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup”. Bissubscribe is a command-line tool that adds subscribers to the TFS notification database (tbl_Subscriptions).

Note: it might be tempting to configure subscriptions directly in the database but currently changes made to the table won’t be reflected until the TFS service is restarted. So to avoid additional headache just use BisSubscribe or the TFS API to manage subscriptions.

The tool can be used for setting up email notifications as well as notifications to a generic web service for application level integration.

The following commands are available in BisSubscribe:

BisSubscribe - Team Foundation Server BisSubscribe Tool

(C) Copyright 2006 Microsoft Corporation. All rights reserved.

BisSubscribe.exe

Usage:

BisSubscribe /eventType <eventType> /address <emailOrSoapAddress> [/deliveryType EmailHtml|EmailPlaintext|Soap] [/server <servername>] [/filter <filterString>] [/tag <tag>]

BisSubscribe /unsubscribe /id <id> [/server <servername>]

where:

eventType:    The name of the event.  Case sensitive.

filter:       (default none) A filter expression.

address:      The email address or webmethod URL for the subscriber.

server:       The Team Foundation Server name.

tag:          (default none) A field to later use to identify this subscription.

deliveryType: (default Soap) EmailHtml|EmailPlaintext|Soap indicating the preferred format.

id:           The integer id for the subscription to be deleted when unsubscribing.

The two parameters that I think requires some extra explanation are:

·         eventType: type of event to subscribe to. See this post of a list of events and how to work with them.

Note: the tool is case-sensitive, so make sure to spell the event type correctly.

·         filter: a filter expression applied to the data passed for the generated event.

The TFS SDK on MSDN has a section on how to use filters. See Filtering Team Foundation Server Events http://msdn2.microsoft.com/en-us/library/bb130302(VS.80).aspx for more details.

So for example to register an email notification based on the check-in event we issue the following command:

BisSubscribe.exe /eventType CheckinEvent /address mathias@win2003 /deliveryType EmailHtml

When working with notifications from TFS it is necessary to know which event to subscribe to. Unfortunately that list is not generally documented so here’s the list of events raised by TFS today: 

Of the events in the list the most commonly used are CheckinEvent for check-in notifications and WorkItemChangedEvent for work item changes.

The following TFS web service can be invoked to get a list of the currently registered events:

http://localhost:8080/services/v1.0/Registration.asmx?op=GetRegistrationEntries

Among the details in the resulting XML we find XML schema definitions for some of the key event types.

In the same folder as BisSubscribe.exe (see the upcoming post for details on using BisSubscribe.exe) we also find XML Schema files for some of the key events. These files are useful when designing filters for the event notifications.

Finally, the list of events can be manually modified using the command-line tool TfsReg.exe.