Sunday, August 26, 2007

TfsBuildLab goes Beta 2

Time sure does fly when you have fun :) it's time for beta 2 (download it from here) almost exactly one month after beta 1 (kinda puts some preassure to finnish the v1 before 22/9)... We have now been dog fooding TfsBuildLab in production since 2007-04-24 on a several projects the largest of them consisting of 5 parallel development branches each containing aproximately 10 000 source files.

Some statistics since the start (didn't have the time to do the graphs this time):

1854 Automatic cleanups
935 Scheduled builds
754 Continous integration builds

What is new in Beta 2?
´
Service

Support for tracing using trace listeners
Made automatic notification registration optional
Removed the need for LDAP to resolve email for notifications
Admin Client
Context menues with refresh commands
Full screen mode (press F11 to toggle)
Added hosting of reports in the dashboard
Minimize to tray
Sorting possibilities on the contents of the grids
Added Edit trigger/policy
Added Copy trigger/policy

Notification Client
Added support for executing alert commands
Notifications occurs when a build starts as well
Policies
A policy for restricting checkins based on a source control path
A policy for restricting checkins when the build is broken
A policy for requiring a comment when performing a checkin

Please let us know if you are using it, if you have troubles installing it or if you have any requests for features. All feedback is wecome.

Thursday, August 23, 2007

LinkMania: HowTo create a custom policy plug-in for Team System

First of all you'll need to download the Team Foundation Server SDK which is included in the Visual Studio SDK.

The most comprehensive guideline is most likely
Creating a Custom Check-in Policy for Team Foundation Server 2005 written by the Patterns & Practices team (sure wish I had this when I wrote my first plug-in).

The documentation on MSDN is also very comprehensive
Check-in Policy Extensibility.

Jim Presto wrote a series of blog posts on this way back that I still think are a very good place to look Create Policy - Step 1 and Create Policy - Step 2 are the best two in my oppinion.

Marcel de Vries obviously had way to much time on his hands when he wrote How to build a custom check-in policy.

Friday, August 17, 2007

Retrieving user email & display name from Team Foundation Server

While working on the continous integration parts in our project TfsBuildLab we needed to resolve a users email based on the accountname retrieved when a checkin notification occurred. My first take was to go straight at the active directory implementing this using LDAP.

However this is some what limiting so I was mucking about and trying to find out how to do it using the TFS api and guess what it isn't that hard at all the following sample illustrates how to do it and at the end of this post I've tried to explain some of the details of the method being used.


using System;
using System.Net;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Server;

public Identity GetUserInfo(string accountname)
{
    string tfsUri = "YOURTFSSERVER";
    string tfsUser = "YOURTFSACCOUNT";
    string tfsPassword = "YOURTFSPASSWORD";

    NetworkCredential nc = new NetworkCredential(tfsUser, tfsPassword);

    TeamFoundationServer tfs = new TeamFoundationServer(tfsUri, nc);

    IGroupSecurityService gss = (IGroupSecurityService)tfs.GetService(typeof(IGroupSecurityService));

    Identity identity = gss.ReadIdentity(SearchFactor.AccountName, accountname, QueryMembership.None);

    if (identity != null)
    {
       //how to get the email
       //string email = identity.MailAddress;

       //how to get the displayname
       //string displayname = identity.DisplayName;

       return identity;
    }

    return null;
}

IGroupSecurityService.ReadIdentity Takes three parameters the first being of the type SearchFactor which lets you specify how you intend to identity the user/group that you which to retrive information about the two most intressting ways (in my oppinion) would be:

SearchFactor.AccountName lets resolve identity based on a windows or tfs identity. The syntax being domain\username or projecturi\groupname

SearchFactor.Sid lets you enter a sid and get back the information about that particular user/user. The syntax being S-1-5-21-1681502023-2202157333-1552196959-1028

The second parameter is where you supply the actual identifier of the type you specified using the SearchFactor.

And the third parameter being of the type QueryMembership is where you specify how groups will be expanded. If you retrieve a group the Identity object you get back contains two member variables called Members (a string array containing the sid's of the members in the returned group empty if it's a not a group) and MemberOf (a string array containing the sid's of the groups the return group/user belongs to). You can specify this in the following way:

QueryMembership.None the quickest way to retrieve the information for a user if you don't need information on which groups he/she belongs to. The aboce mentioned variables Members and MemberOf will be null when using this.

QueryMembership.Direct will not expanded any groups that are members, but simply return the group as one sid.

QueryMembership.Expanded will expand any groups that are members and return the sid's for the contained users in the group.