New Team System Home on MSDN

9 02 2009

Team System now has a new home on MSDN which is cleaner, easier to navigate, and has been cleaned up to remove redundant and inaccurate information. Let the team know what you think by leaving feedback.





Inside the Microsoft Build Engine Now In Stock

15 01 2009

My first book Inside the Microsoft Build Engine is now In Stock at Amazon. So, go forth, purchase a copy, read it, post a review!





Implementing Delta Builds Using Team Build

7 01 2009

Thomas Janssen has an interesting blog article about how to implement Delta Builds using Team Build. With incremental builds (which are supported by Team Build) all of the assemblies (regardless of whether they were built during the current build or previous builds) are dropped to the drop location. However, delta builds only drop the assemblies that have changed since the baseline. Via Sayed Ibrahim Hashimi.





Get a 10% discount and an opportunity for a free retake on a Microsoft Certification Exam

7 01 2009

It’s a New Year and a great opportunity to complete those certification exams you’ve always been meaning to do. Microsoft have just the promotion to give you that push.

Go to www.learnANDcertify.com and key in AU2EAEAB and complete the Request Form. You will receive an Exam Offer Voucher Code valid for a 10% discount on your first Microsoft Certification exam and if you fail on your first try, a free retake of the same exam (both exams must be taken by May 31, 2009)

Terms & Conditions:

  • The Exam Offer Voucher Code are only valid for a Microsoft Certified Technical Specialist (MCTS), Microsoft Certified IT Professional
    (MCITP) or Microsoft Certified Professional Developer (MCPD) exams. Not valid for Academic Exams.
  • The Exam Offer Voucher Code is only valid for exam candidates in the country where the MVP resides.
  • The Exam Offer Voucher Code may only be used at an authorized Prometric Testing Center
  • Exam candidates must request an Exam Offer Voucher Code using the unique MVP Certification Promotion Code by March 31, 2009 via
    www.learnandcertify.com
  • To receive a 10% discount on the cost of an applicable Microsoft Certification exam, exam candidates must use the Exam Offer Voucher Code provided by an MVP when they register for an exam and sit for an exam by May 31, 2009.
  • Limited to one (1) free exam and one (1) free retake (if necessary) per individual.
  • The Exam Offer Voucher Code may only be used by the exam candidate receiving the Voucher Code and may not be transferred to and/or used by any other individual.
  • The Exam Offer Voucher Code may not be combined with other vouchers or discounts and are void if altered or revised in any way.
  • The Exam Offer Voucher Code may not be redeemed for cash, credit, or refund.
  • Microsoft is not responsible for Exam Offer Voucher Code that are lost or stolen.
  • Any resale of an Exam Offer Voucher Code is expressly prohibited.




Test Driven Development and Keybindings

22 12 2008

For those that practice Test Driven Development (TDD) here’s a quick reminder about keybindings in Visual Studio 2008 that will make your life easier:

  • Run all tests in the solution – Ctrl+R, A
  • Run tests in the current class – Ctrl+R, C
  • Run tests in the current context – Ctrl+R, T
  • Run tests in the current namespace – Ctrl+R, N

There is also a variant which debugs the tests, to use this variant hold down Ctrl when pressing the second key in the chord.

I also like to bind Ctrl+N, T to Project.AddNewTest and Ctrl+N, U to Project.AddUnitTest so I can quickly add tests to the current test project.





API Note #1: Getting Started

9 12 2008

Welcome to the first of many posts about the Team Foundation Server API. These posts will explore the various namespaces and classes available to programmatically integrate with the components of Team Foundation Server including build, source control, reporting, testing, and work item tracking.

Most examples in this series are written as C# console applications for simplicity but these concepts can be used in Windows Forms, WPF, WCF, ASP.NET, or any other technology or language that can use .NET assemblies.

The example projects will be attached to each post for you to download.

Assumptions

This series of posts assumes that you are familiar with both Visual Studio Team System 2008 and Team Foundation Server 2008 from a user’s and/or administrator’s perspective.

Prerequisites

The first step is to make sure you have all of the prerequisites to follow the examples we go through.

Registered Servers

The first API we’re going to look at is Microsoft.TeamFoundation.Client.RegisteredServers which provides access to the list of Team Foundation Servers that are registered on the client machine. This is the API that is used to populate the Add/Remove Team Foundation Server dialog in Visual Studio:

addremoveteamfoundationserver

 

Since this is our first time using the API we’ll go through this example in more detail than we will for later examples.

  1. Create a new C# Console Application.
  2. Add a GAC reference to Microsoft.TeamFoundation.Client version 9.0.0.0.
    addreference
  3. Add a using statement to import the Microsoft.TeamFoundation.Client namespace:
    using Microsoft.TeamFoundation.Client;
  4. Add the following code, which will simply print the name of each registered server, to the Main method:
    foreach (string registeredServerName in RegisteredServers.GetServerNames())
    {
        Console.WriteLine(registeredServerName);
    }
    
    Console.ReadLine();

Rather than retrieving just the server name we can retrieve a TeamFoundationServer object (which we’ll discuss in more detail later in this post) representing the server by calling the GetServers method. This example produces the same output as the previous one:

foreach (TeamFoundationServer registeredServer in RegisteredServers.GetServers())
{
    Console.WriteLine(registeredServer.Name);
}

We can also use the RegisteredServers class to add servers to or remove servers from the list of registered servers as shown in this example:

if (args.Length != 1)
{
    Console.Error.WriteLine("USAGE: AddRegisteredServer.exe <teamFoundationServerUrl>");
    return;
}

string teamFoundationServerUrl = args[0];
TeamFoundationServer teamFoundationServer = TeamFoundationServerFactory.GetServer(    teamFoundationServerUrl);
RegisteredServers.AddServer(teamFoundationServer);

The AddServer method only accepts a TeamFoundationServer object and not a string so we use the TeamFoundationServerFactory (which we’ll discuss in more detail later in this post) to retrieve one.

TeamFoundationServer vs TeamFoundationServerFactory

The TeamFoundationServer class is one of the most important in the API as it represents a connection to a Team Foundation Server. There are two ways of creating a TeamFoundationServer object:

  1. Directly creating an instance of the class passing the URL of the Team Foundation Server (or just the hostname) to the constructor:
    TeamFoundationServer teamFoundationServer;teamFoundationServer = new TeamFoundationServer("http://T1W102826-TFS2K8:8080");
  2. Passing the URL or hostname to the static GetServer method on the TeamFoundationServerFactory class:
    TeamFoundationServer teamFoundationServer;teamFoundationServer = TeamFoundationServerFactory.GetServer("http://T1W102826-TFS2K8:8080");

So which should you use? The best practice is to use the TeamFoundationServerFactory because it caches the TeamFoundationServer objects based on their URI. This improves performance by reusing connections and avoiding having to re-authenticate (which is particularly important to avoid unnecessary authentication prompts if the user isn’t authenticated automatically). Regardless of whether you request the server by name or by URI, it will be cached based on the case-insensitive URI, but ideally you should use either the name or the URI consistently.

Authenticating

When you call an API that requires authentication it calls the EnsureAuthenticated method on the TeamFoundationServer object to check if the user is already authenticated and start the authentication process if they’re not.

Initially the API tries to authenticate the user using their Windows credentials and throws a TeamFoundationServerUnauthorizedException if this fails. There are three possible ways to avoid this:

  • Pass a credential object to the TeamFoundationServer class constructor.
  • Pass a credential and credential provider object to the TeamFoundationServer class constructor.
  • Pass a credential provider object to the TeamFoundationServerFactor.GetServer method.

If the TeamFoundationServer object has a credential object this will be used instead of the user’s Windows credentials to initially authenticate the user. But if this fails a TeamFoundationServerUnauthorizedException will still be thrown unless a credential provider object has been specified.

If a credential provider has been specified then its GetCredentials method will be called to provide the fallback credentials to use. If authentication using these fallback credentials succeeds then the API calls the credential provider’s NotifyCredentialsAuthenticated method. The API ships a single credential provider, UICredentialsProvider, that displays the standard login dialog and returns a credential based on what is entered:

authenticationdialog

 

This example passes a UICredentialsProvider to the TeamFoundationServerFactory.GetServer method. If authentication can be completed automatically using the user’s Windows credentials then it will be, otherwise the user will be prompted to enter their credentials:

TeamFoundationServer teamFoundationServer;
teamFoundationServer = TeamFoundationServerFactory.GetServer(
    "http://T1W102826-TFS2K8:8080",
    new UICredentialsProvider()
);
teamFoundationServer.EnsureAuthenticated();

Once the user has been authenticated you can retrieve their details through the AuthenticatedUserName, AuthenticatedUserDisplayName, AuthenticatedUserIdentity, or Credentials properties on the TeamFoundationServer object:

Console.WriteLine("{0} = {1}",     "AuthenticatedUserName", teamFoundationServer.AuthenticatedUserName);
Console.WriteLine("{0} = {1}",     "AuthenticatedUserDisplayName", teamFoundationServer.AuthenticatedUserDisplayName);

Conclusion

In this (lengthy) post we’ve looked at how to reference the Team Foundation Server API, work with registered servers, access TeamFoundationServer objects, and authenticate to Team Foundation Server. Stay tuned for the next post where we look at how to access the various components of Team Foundation Server.

Download sample files for API Note #1: Getting Started.





Inside the Microsoft® Build Engine: Using MSBuild and Team Foundation Build

1 12 2008

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.





Preserving Labels When Builds Are Deleted

21 10 2008

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.





Team Foundation Build Load Balancer Released

21 10 2008

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.





Open-Source Project for Pre Check-In Validation

10 10 2008

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:

  1. Developer shelves their changes.
  2. Developer starts a build using the BuddyBuild menu in Visual Studio:
    image1
  3. Developer selects the shelveset they want to build and clicks Queue Build. 
     image2
  4. The TFS Check-In Validation Tool extends the default build process to get the shelveset after the normal get has been performed so that the developer’s changes are built as well. If the build succeeds then it can also (optionally) check-in the shelveset automatically.

Leave your feedback on the Discussions tab or raise an bugs or issues on the Issues tab.