When builds are deleted in TFS 2008, either manually or via retention policies, everything about the build is deleted, including the label. This completely removes the ability to reproduce the build in the future if the need arises.
In Service Pack 1 the capability was added to have labels preserved when the build is deleted and Buck explains how to enable this in his blog post.
I’ve released a new open-source project that we’ve been using internally for a number of months called the Team Foundation Build Load Balancer (http://www.codeplex.com/teambuildloadbalance/). It’s a very simple command-line application (which is designed to be run in a scheduled job) to balance queued builds between multiple build agents irrespective of which build agent it was queued on.
A new open-source project has been released on CodePlex called the TFS Check-in Validation Tool. The main purpose of this project is to allow developers to run their changes through a full end-to-end build prior to checking them in.
It works basically like this:
Leave your feedback on the Discussions tab or raise an bugs or issues on the Issues tab.
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:
When you create a new test project the following files are added to it by default:
You can configure what files are added in Tools | Options | Test Tools | Test Project as shown here:
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.
Paul Hacker and Dave McKinstry have started a virtual Team System user group which will use collaboration technologies like Live Meeting and SecondLife to create a global user group for Team System. For more information and to register visit:
The first meeting will be held on September 18, 2008 at 6:00 PM SLT.
But don’t forget to also visit the real life user groups such as the Queensland VSTS User Group to get your fix of real life mingling and interaction as well as being able to feed yourself, not just your avatar.
