I’m proud to say that after many months of work Sayed Ibrahim Hashimi and I have completed work on Inside the Microsoft® Build Engine: Using MSBuild and Team Foundation Build (PRO-Developer). It is being published by Microsoft Press and is due out on 7th January 2009.
When users subscribe to a report via email in Reporting Services the destination email address field defaults to their username and is read-only. If the SMTP server that you’re using won’t accept emails for plain usernames then you will have to allow users to enter their full email address when subscribing to a report.
To do this:
On Friday at the Queensland VSTS User Group Matthew Rowan mentioned an open-source system tray utility he’d written called TFS Working On. This utility allows developers to select the work item they are currently working on and it will record the time spent, add it to the work item’s history, as well as updating the work completed and work remaining fields appropriately.
Matthew will be presenting at the December user group meeting about this and how they leveraged the Team System OLAP cube for reporting time and doing evidence-based scheduling.
Brian Harry has blogged about the upcoming power tools release and this is without a doubt the biggest yet, here’s a couple of the highlights to whet your appetite:
There are numerous examples around that explain how to receive TFS events using an ASMX web service. In this post we’ll look at how you can create a WCF service, hosted in IIS or self-hosted, to receive these events.
Prerequisites
Create a WCF Service
The first step is of course to create a WCF service project. In Visual Studio 2008 create a new WCF Service Library using the language of your choice but in this example we’ll use Visual Basic .NET. If you do not see the WCF option select either .NET Framework 3.0 or .NET Framework 3.5 from the dropdown list in the top right-hand corner of the New Project dialog.
This will create a project containing an app.config (which stores the WCF configuration), IService1.vb (which stores the service’s interface), and Service1.vb (which stores the service’s implementation). The new project should look like this:
Renaming the Service Interface and Service Implementation
IService1 and Service1 aren’t the most descriptive names, so we’ll rename them to TfsEventSubscriber and remove the sample service implementation. To do this:
The resulting project should look like this:
Define the Method to Receive TFS Events
The next step is to define a method that will receive the TFS Events. The name of this method is up to you but the convention is to call it Notify and it must accept two string parameters called eventXml and tfsIdentityXml. The eventXml argument will contain the XML about the event occur and this will conform to the schema for that particular event. The tfsIdentityXml argument will contain XML identifying the application tier that raised the event.
We now add this method to the ITfsEventSubscriber and apply the OperationContract attribute. We also need to specify the namespace and action named used by Team Foundation Server when calling this operation. This results in the interface looking like this:
<ServiceContract(Namespace:="http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03")> _ Public Interface ITfsEventSubscriber <OperationContract(Action:="http://schemas.microsoft.com/TeamFoundation/2005/06/Services/Notification/03/Notify")> _ Sub Notify(ByVal eventXml As String, ByVal tfsIdentityXml As String)End Interface
For the project to compile we must implement this new method in the TfsEventSubscriber which would then look like this:
Public Class TfsEventSubscriber Implements ITfsEventSubscriber Public Sub Notify(ByVal eventXml As String, ByVal tfsIdentityXml As String) Implements ITfsEventSubscriber.Notify End Sub End Class
Writing the Implementation
You can now extend the Notify method to provide your service’s implementation. In our example we simply dump each request out as a uniquely named XML file:
Imports System.IO Public Class TfsEventSubscriber Implements ITfsEventSubscriber Public Sub Notify(ByVal eventXml As String, ByVal tfsIdentityXml As String) Implements ITfsEventSubscriber.Notify File.WriteAllText(Path.Combine(Path.GetTempPath(), Guid.NewGuid.ToString() & ".xml"), eventXml) End Sub End Class
Configure the WCF Service
There are a number of changes that need to be made to the WCF Service’s configuration, these can be made by editing the app.config file directly or by using the WCF Configuration Editor shown here.
We need to change the binding from wsHttpBinding to basicHttpBinding.
Because Team Foundation Server will never access the metadata service we can safely remove it from our configuration. Firstly we delete the endpoint that implements the IMetadataExchange contract.
Then we remove the serviceMetadata behaviour:
Testing and Debugging Your Service
If you run the project using Visual Studio it will automatically host your service using the WcfSvcHost that ships with Visual Studio 2008. While the project is running in Visual Studio then all of the usually debugging tools (such as breakpoints) will be available.
Once the service is running you can use BisSubscribe.exe from the Visual Studio 2008 SDK to add a subscription to Team Foundation Server so that your service is called when events are raised. In this example we add a SOAP subscription to the BuildStatusChangedEvent using the URL that Visual Studio hosted our service:
BisSubscribe.exe /eventType BuildStatusChangedEvent
/address http://DEVWORKSTATION:8731/Design_Time_Addresses/ReceiveTfsEventsUsingWcf/TfsEventSubscriber/
/server http://TFSRTM08:8080/
/deliveryType Soap
If you have a firewall, including the one that ships with Windows, you may need to disable it or add an exception for the port that the service has been hosted on.
Deploying Your Service
Once you’ve built and tested and your service you can host it using any of the hosting methods supported by WCF (such as using IIS or self-hosting) and then use BisSubscribe to add the necessary subscriptions.
Brian Harry has published a list of bug fixes that shipped in TFS 2008 Service Pack 1. What I also found interesting from this list is the breakdown of where different bugs were detected or reported.
After upgrading one of our production environments to Visual Studio Team System 2008 whenever I launched Microsoft Word (or something that uses Microsoft Word such as Microsoft Outlook) the Windows Installer dialog would appear and after some time complain that it could not write to C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat. Because I’m running Windows Vista I don’t by default have write access to the files under C:\Program Files\ and the installer wasn’t prompting me to escalate my privileges which resulted in the installer failing.
I thought the solution to the problem was to explicitly launch Microsoft Word as administrator once to allow the installation to complete successfully. Unfortunately it appears to be a per-user installation, so what I had to do was temporarily grant the Users group Full Control to C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat to allow the installation to complete as the current user.
UPDATE: This made the installation succeed but didn’t stop it running every time I launched an Office product.
UPDATE 2: It turns out that this was actually caused by a conflict with the WinZip Email Companion add-in. Disabling this made the problem go away.
I’ve been doing some work today on extending the Team Foundation Server UI, for example integrating with Team Explorer and the Pending Changes windows. I came across a number of resources explaining how to achieve this:
How to get the active Team Foundation Server and Project from an Add-In
Extending Team Foundation Server Version Control for Team Build Types Visual Studio integration
How to Write a Team Foundation Version Control Add-in for Visual Studio
Extending VSTS Work Item Tracking UI: Accessing work item UI elements and responding to events
Work Item Tracking v1 Client Extensibility in Visual Studio Team System
If rolling the Team Foundation Server Power Tools out to a number of users (which you will need to do if you want to use the check-in policies) you will probably want to run the installation unattended.
There are two tricks:
I used dark.exe from the WiX Toolkit to determine the ProductCode and thanks must go to Hua Chen from Microsoft for helping out with how to exclude the Best Practices Analyzer and the Process Editor.
I’m doing a lot of work with Work Item Type Definitions and for those that don’t know the Visual Studio SDK includes schemas for these that can be used in Visual Studio (and other XML editors) to provide Intellisense capabilities.
Rob Caron blogs about this here. For those that don’t want to download the whole SDK he also provides a direct download of just the schemas.
