Martin Woodward

Many people know that Team System and Team Foundation Server are incredibly extensible platforms.  Mike Azocar (a fellow Team System MVP) has come up with a great idea to see up can come up with the coolest Team System add-on.  If you have an idea that you've been waiting on trying out then now might be a good time as you get the chance to win a one year Team Suite MSDN Subscription (worth over $10,000) among other valuable prizes and the exposure for your gadget on most of the world's leading Team System blogs.

Because I doubt I'm going to be able to do better than my robot rabbit TFS add-on, I'm going to help judge the competition.  I am really looking forward to seeing what folks can come up with.

For more information, see Mike's blog post.  Happy coding!

I am proud to announce that Microsoft have just published a joint case study with us on the success Thomson Reuters have had using Team Foundation Server in a mixed development shop.  This customer is particularly interesting, not just because they keep giving us great feedback on our product that we have been incorporating into Teamprise, or because they are a large, well know and well respected brand.  From the case study;

"The Online Services group at Thomson Reuters is responsible for the storage and retrieval of online assets. Of the 220-member team, approximately 150 are development engineers or quality engineers. Although the team does some programming using the Microsoft® .NET Framework, the group primarily develops in Java on computers that run a variety of operating systems, including Linux, Linux 64, UNIX, Macintosh, and Windows®. About 90 percent of the programmers in Online Services work in Eclipse or Rational Application Developer (RAD), and up to 50 percent of the testers work in Eclipse. All of the team’s build computers run UNIX or Linux."

Anyway, thanks to Mac and the people at Thomson Reuters for agreeing to share their experiences.  Hopefully other organizations considering Team Foundation Server to manage the whole software development process will find the case study interesting.

To read the case study in full, see Microsoft Case Studies: Thomson Reuters Unify Development Processes with Team Foundation Server and Teamprise.  I've also got a PDF version available here.

I've been doing a lot of work with the Team Foundation Server 2008 SP1 Preview, and even recorded a podcast about it (also see Brian Harry's blog post for more details on TFS 2008 SP1 features).

One out of the many new features introduced in TFS 2008 SP1 is the "Last Check-in" column in the source control explorer. It is a handy little thing that I think a lot of people will find useful. 

However just a couple of warnings for you for behaviour that you might not expect at first.

1. The date shown for folders is the date that the folder was added, not the last date that any contents of that folder where checked in.  That means you cannot use it to drill down onto the most recently changes files - to find that out you should still do a "View History" on the parent folder and look at the changesets.
2. If you are using a Visual Studio 2008 SP1 client (or Teamprise 3.1 for that matter when it is released) and you point it at a server prior to TFS 2008 SP1 (i.e. TFS 2005 or the RTM release of TFS 2008) then you do not get any data in this column because the server doesn't send back that data to the client.

Otherwise it works pretty much as you expect.  Most useful is that you can obviously sort the column to find the recently changed files in a big list of files.

It turns out that the little video I posted yesterday has taken on a bit of a life of it's own.  Last time I checked, it was in the top 10 Science and Technology posts for YouTube in Ireland.  It's funny how it is always the posts that you do more for your own entertainment that take off. 

Anyway, there is no doubting that Brian is a bit of a character, he's already recorded his first TV appearance as a guest on this weeks, "This Week in Channel 9" (to be broadcast soon).  I wish that Nabaztag had an affiliate program as it sounds like I may have sold a few rabbits for them. 

Anyway, if you can't afford your own bunny, then you can have the next best thing for free.  Your very own Brian the Build Bunny Background on the desktop of a computer near you (standard and widescreen versions available).  Click here to chose a image size that suits you.

I'm always keen try new and novel ways to keep in touch with the status of my software projects.  Fortunately, Team Foundation Server provides many ways to do this.  While the Build Wallboard is fun if you have a spare monitor and machine lying around, I wanted to experiment with some inexpensive dedicated devices, and so Brian the Build Bunny was born.

Brian is a Nabaztag smart rabbit.  He reads out details of check-ins and builds.  If a build has failed then his ears go down to show how sad he feels, but if you fix the build his ears will soon pick up again.

I've had Brian for about a year now waiting to do this project, but when I tried it in the past I always found the response times from the rabbit to be too slow.  However earlier this year, the Nabaztag developers updated the code running the rabbits so that they are now using the XMPP (Jabber) protocol to receive updates and the service now seems pretty good.

Brian is now sitting on my desk chattering away and letting me know what is happening in TFS.  If you want to find out more about how he works and see him in action then take a look at the video. If your company blocks YouTube but you have Silverlight installed then you can view a higher quality version of the video courtesy of the Windows Live Streaming service.  I'll go through the code behind Brian in a later post if there is any interest, but it is pretty much a standard TFS event listener that then sends text to the rabbit using the Nabaztag API.

I've just posted the latest installment of Radio TFS.  I'm actually a show behind on editing so expect to see episode 6 up soon.  However, in episode 5 Paul, Mickey and I attempt to answer some of the common questions we hear people ask about Team System including:

• What is Team System?
• Which edition is right for me?
• Why can't I find Team Foundation Server on MSDN?
• What is Team Foundation Server Workgroup Edition?
• Is VSTS 2005 compatible with TFS 2008?
• Why can't I see Team Foundation Server when I install Team Suite?
• What are my options for migrating from my old system(s) to TFS?
• Can I use TFS with VB6, .NET 1.1, Eclipse etc?
• What is a Team Project - how should it be scoped?
• I deleted a file locally, I do a "Get Latest" and TFS doesn't download it - why?

As well as the usual sprinkling of tangents along the way.

Click here for a direct link to this episode.

If you have any questions that you would like answered, or if you have any comments and feedback about the show then please contact us at radiotfs@gmail.com or visit the website at http://radiotfs.com for quick links to subscribe to the feed in iTunes, Zune etc.

Infragistics is the world's largest publisher of reusable presentation layer development tools for Windows Forms, ASP.NET, WPF, Tablet PC and Java (JSF) environments.  I think they can count most of the Fortune 2000 as customers of theirs.  They also happen to be a customer of ours. 

I was in an email discussion with fellow MVP Ed Blankenship, when he came out with the following quote which Infragistics have kindly given me permission to share.

“We completely use Microsoft® Team Foundation Server (with Teamprise) for the development of all of our products now.  This was especially challenging with bringing in our Java (JSF) development group into the same development process of our .NET product lines.  By leveraging the Teamprise Eclipse plug-in and the ANT Team Build tasks, we were able to ensure they were using the exact same systems as the other departments in Engineering.  So the JSF team now has access to the same build, version control, work item tracking, and other internal automated software solutions that the rest of our company uses.  Visual Studio® Team System has really enabled us to solidify our internal ALM process, metrics gathering, and reduce overhead from supporting different systems across product teams.”

Ed Blankenship
Infragistics

Thanks for sharing Ed!  On a personal note, I'm glad that the Ant integration is proving so useful to many companies and this is an area that we are going to continue investing in along with everything else.

As we all know by now - the build system in TFS2008 was substantially improved.  Along with the many improvements came an official API for talking to the build system.  This is the same API that the Team Foundation Build UI in Visual Studio uses, however there are many additional methods that were added that were not for the UI at all but for potential consumers of the Build API.

In talking with folks at community events, and on the MSDN forums I have realized that there isn't a huge awareness of this API.  Having written a parallel implementation of the build API, but in Java for the Teamprise 3.0 release I have spent a great deal of time with the .NET API and have a few examples lying around of how to accomplish certain common tasks - so I thought I would run through a some of them.  If you have an example of something you would like to see with the build API then please leave a comment for this post or drop me a line.

So - let's start with a basic one.  How to queue a build.  This will introduce us to a few concepts with-in the build API that are common across all of the methods.

The Easy Way.

A quick look at the class diagram above will show you that the main interfaces you'll be dealing with in the Build API are the IBuildServer and IBuildDefinition interfaces.  To get started with these you'll need to add references to the Microsoft.TeamFoundation.dll, Microsoft.TeamFoundation.Client.dll and Microsoft.TeamFoundation.Build.Client.dll.

C#

TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer("http://tfsserver:8080”);
IBuildServer buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));
IBuildDefinition buildDef = buildServer.GetBuildDefinition("TeamProject", "Build Name");
buildServer.QueueBuild(buildDef);

VB.NET

Dim tfs As TeamFoundationServer = TeamFoundationServerFactory.GetServer("http://tfsserver:8080")
Dim buildServer As IBuildServer = DirectCast(tfs.GetService(GetType(IBuildServer)), IBuildServer)
Dim buildDef As IBuildDefinition = buildServer.GetBuildDefinition("TeamProject", “Build Name")
buildServer.QueueBuild(buildDef)

I'm afraid that's the last example you'll be seeing in VB.NET.  Being a Java developer by day I tend to like my semi-colons.  However if you are a VB developer then hopefully you'll be able to follow along as the rest of the examples are more or less just method calls with the occasional bit of casting.

So - what's going on here.  Well we first get hold of a TeamFoundationServer object.  If this was server side code and we wanted to specify some credentials then we would use a slightly difference mechanism but in this case the constructor works well and this will automatically connect using the credentials of the current thread.

Next we get hold of the build service that implements the IBuildServer interface.  Finally we get a hold of the build definition by specifying a team project and build definition name (build definitions are unique per team project in TFS).  We then queue a build using the defaults for that build definition.  This API call is actually shorthand for the following...

The Hard Way

Supposed you want to queue a build, but you don't want to use the default build agent, priority, drop location etc.  Well in that case you need to look at the IBuildRequest interface.  Here you will find all the options to customize the build request, you can specify a build agent, drop location, priority etc like you can do from the Visual Studio UI.  You will also find other options such as being able to queue the build with a maximum acceptable queue position, pass a custom get version for the build or even queue the build in a postponed status.

In the following example, I am going to find a non-default build agent from the server and then queue a build using it.

        TeamFoundationServer tfs = new TeamFoundationServer("http://tfsserver:8080");
        IBuildServer buildServer = (IBuildServer)tfs.GetService(typeof(IBuildServer));

        String teamProject = "TeamProject";

        String buildDefinitionName = "MyBuildDefinition";

        String buildAgentName = "MyBuildAgent";

        

        // Find our (non default) build agent.

        IBuildAgentQueryResult queryResult = buildServer.QueryBuildAgents(buildServer.CreateBuildAgentSpec(teamProject, buildAgentName));

        if (queryResult.Failures.Length > 0 || queryResult.Agents.Length != 1)

        {

          throw new Exception("Invalid Build Agent");

        }

        IBuildAgent buildAgent = queryResult.Agents[0];

        IBuildDefinition buildDefinition = buildServer.GetBuildDefinition(teamProject,buildDefinitionName);

        // Create a build request based on our chosen definition.

        IBuildRequest buildRequest = buildDefinition.CreateBuildRequest();

        // Optionally set command line args, drop location, priority, custom source version etc here

        // in this case just overriding default build agent.

        buildRequest.BuildAgent = buildAgent;

        buildServer.QueueBuild(buildRequest);

Pretty simple really and very powerful.  I encourage you to go take a look at the IBuildServer interface to see some of the stuff that you can do.  If you have any suggestions as to what you would like to see as a build API example then leave a comment to this post.

I've just posted the fourth episode of Radio TFS.  In this episode Paul and Mickey talk about Visual Studio Team System 2008 Development Edition while I ask dumb questions and go off on tangents.  Despite this, it is actually one of our better episodes to date.  So if you are interested and have a spare 35 minutes during a commute or something then please take a listen and let us know what you think.

Click here for a direct link to the show.

Don't forget to subscribe in iTunes, or subscribe in Zune if you have either of those applications installed.

Thanks to everyone who attended my session this afternoon at IMTC 2008 in Dublin.  As promised, here is a copy of the slide deck. 

• Automating Builds with Team Foundation Server 2008 (pdf - 1.26 MB)

Also, as mentioned - the Build Wallboard project that we did as a demo is also available at the MSDN Code Gallery here:

http://code.msdn.microsoft.com/buildwallboard

Jeffrey Fredrick just announced that CruiseControl 2.7.2 is now available for download: http://tinyurl.com/2zm9mz.

There are lots of bug fixes, lots of changes to the Dashboard and some new plug-ins, but the bit that is of most interest to me was (from the release notes)

TeamFoundationServer source control
----------------------
* Fix compatibility with Microsoft Visual Studio Team Foundation Server 2008 (CC-735). Submitted by Martin Woodward.

This was to work around an issue that came up when using CruiseControl (java version) to talk to a TFS2008 server (TFS2005 worked fine and still does).  If you are attempting to use CruiseControl with TFS 2008 then you should go with CruiseControl 2.7.2.  For that matter - if you are using CruiseControl.NET with TFS then you should also take a look at the latest release of the integration to TFS - as that contains the same fix allowing you to happily talk to a 2008 version of Team Foundation Server (also using the TFS 2008 client API's).

Anyway, congratulations to the CruiseControl team on the 2.7.2 release!

UPDATE: Just heard from Brian Randell that the VPC is now ready to download.  Updated links are below.

Anthony Borton just pointed out to me that the new version of the Team System evaluation VPC is available.  The Virtual PC is the best way to easily take Team System for a quick spin, as it comes with everything installed.  This release also contains 38 hands-on labs WITH sample data - awesome work.

I am downloading it right now.  For those folks who are fans of the Free Download Manager, here is a list of URL's that you will need to download the Virtual PC.

http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0001.exe
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0002.rar 
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0003.rar 
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0004.rar 
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0005.rar 
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0006.rar 
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0007.rar 
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0008.rar 
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/en_visual_studio_team_system_2008_team_suite_and_tfs_rtm_vpc_march2008.part0009.rar 
http://download.microsoft.com/download/d/7/3/d73b91d4-6daa-4da6-8635-3f10a1b918db/VSTS 2008 Hands-on Labs March 2008 Release.msi

Or you can simply visit the download page and download them in your browser if you prefer

http://www.microsoft.com/downloads/details.aspx?FamilyID=c7a809d8-8c9f-439f-8147-948bc6957812&DisplayLang=en

The Team System Chat's are a great way for you to talk direct to very influential members of the product group - the people that actually write the code behind team system.  If you have a query or there is a feature that you would really like then this is a great way of talking to the people direct and getting your feedback heard.

So, join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

Add to Calendar

April 9, 2008, 10am Pacific, 6pm BST
Additional Time Zones

At EclipseCon 2008 this morning, we just announced that Teamprise 3.0 has been released!  If you've been wondering why I have been quiet on the blog lately - but also why anything I have been talking about is Team Foundation Build related, then you are about to find out why :-)  First of all, I'd encourage you to go visit the shiny new website at http://www.teamprise.com.  Our marketing team had too much fun putting that together, including getting a real, live, massive Teamprise power button made up and shipped in a huge crate from New York to be photographed and used as the new site/icon image.

The full release notes are available here, but as has been the tradition for the past few Teamprise releases, I thought I would give you a run down of my favourite new features in the 3.0 release.

At a high level, the features in 3.0 can be summarised as:-

• Full Team Foundation Build integration (including ability to execute Ant based builds)
• Check-in policy support
• Recursive folder compare
• Single sign-on (from Microsoft Windows machines)
• "Destroy" command for version control
• Show deleted items and undelete from Source Control Explorer UI
• much much more (see release notes)

While it is not my area, I should also mention that we've taken this opportunity to make our licensing more affordable for smaller teams.  We have been very pleasantly surprised by the number of people buying 1 to 20 licenses at a time.  Originally, Teamprise pricing was skewed to the Enterprise customers (i.e. simple, all inclusive and with steep volume discounts).  So we have done a couple of things to help out the smaller companies:-

• You can now purchase the various components (Teamprise Plug-in for Eclipse, Teamprise Explorer, Teamprise Command Line Client) individually as well as the Teamprise Client Suite which gives you the lot.
• We have lowered the initial prices for a single seat, meaning that people buying one or two licenses can now get the same discounts that used to only be available to folks purchasing 100.

If you have any licensing issues / queries then feel free to contact me, or you can talk to the sales team direct at sales@teamprise.com.  Anyway - back to the part of this release that I do know about - the technology. 

The first feature I want to talk about is one that I had no involvement with.  It's one of those features that many people will not notice because it just works but anyone who has done any Java to .NET web service interop work will instantly recognise as being a little bit clever.

Single Sign-On

The initial log-in screen has undergone a big overhaul.  On Windows machines you are given the option to use "default credentials", i.e. the username and password that you are logged onto windows with.  It obviously doesn't know your password, but does some JNI magic to get the native Windows API's to handle the authentication logic with Team Foundation Server.  While you are also on the login screen, you may notice the Profile feature.  This is an area that many people probably won't use, but we added for our power users and for ourselves.  Basically, the profiles feature allows you to store sets of servers/credentials that you commonly use to connect to Team Foundation Server and then you can bring up the details using a simple drop down.  Makes it much easier to switch between your production TFS instance and your CodePlex project for example - or switch credentials if you are a TFS administrator.

Check-in Policy Support

In Visual Studio, check-in policies are implemented as a .NET assembly runs every time a policy is evaluated or configured.  The policy also has full access to the .NET API's, the Visual Studio API's as well as anything it might want to pinvoke out to on the Win32 API side.  As you can imagine, this presented us some problems when we wanted to have check-in policies that ran the same in Eclipse on Windows Vista as Teamprise Explorer on the Mac or Aptana on Ubuntu - therefore we have had to develop a parallel Teamprise check-in policy framework.

As we were doing this, we took the opportunity to learn from some of the feedback folks have been having with the Visual Studio check-in policies.  While our framework and SDK will look very familiar to anyone that has developed a custom check-in policy for Visual Studio, you will notice some differences.

Firstly, we supply different policies out of the box.  The vast majority of custom check-in polices that people deploy are things like "Check for Comments" etc, so we just shipped the common ones our customers wanted to prevent them from having to write their own.

Secondly, we make use of the Eclipse plug-in framework to implement our policies as extension points.  This means that they are easy to deploy (using the Eclipse update site mechanisms built in to the IDE).  We have also separated the configuration (stored as a blob of XML data in our framework) from the implementation - represented by the plug-in deployed.  The again makes it easier to deploy, especially when it comes to version 2 of a policy...

Thirdly, all of our policies can be scoped by the path in version control to which they correspond - you are not limited to per Team Project scoping and you do not have to wrap your policies in a custom policy to get more detailed scoping like you do with the current Visual Studio framework.

Team Foundation Build Integration

Anyone that has been following this blog for a while, or who attended the Team Build talk I did at TechEd with Brian Randell, will notice that I have been increasingly involved in the inner workings of Team Foundation Build.  Now you can see the fruits of that labour.

In Teamprise we now have full integration with the shiny new build functionality in TFS 2008 as well as support for TFS 2005.  Backwards compatibility with the TFS 2005 server is very similar to if you were using a Visual Studio 2008 client, accept that ours is slightly more backwards compatible (you can create new builds on a TFS 2005 server as well as manage build qualities etc).  However it is with TFS 2008 that you get to see the majority of the features.  I could go on about this aspect all day as their are so small things that I am proud of, but at a high level you can:

• View existing build definitions
• Manage builds in Build Explorer
• Queue new builds
• View build report
• Edit Build Quality
• Delete build
• Manage Build Qualities
• Open Drop Folder
• New/Edit Build Definition

• Edit Retention Policies
• Keep Build
• Set Queue Priority
• Postpone Build
• Stop/Cancel Build
• Delete Build Definition

One of the smaller features I will call out is that from the build definition in the Team Explorer, you can right click and do a "View Build Configuration" that will open the Source Control Explorer at the place in which the TFSBuild.proj file is stored so that you can check it out and edit it.  A feature that I added solely for my own sanity during dogfooding :-). 

All this would be fairly academic, if you didn't have some way to do a cross-platform build using Team Foundation Build.  In the current release, we provide a the Teamprise Extensions for Team Foundation Build which basically Ant enables the Team Foundation build server.  The Teamprise extensions are a set of MSBuild targets that insert the Ant build process into the standard Team Build mechanism as well as a custom MSBuild We hope to extend this to support in the near future to some of the other common build/test tool-chains in the cross-platform world.  However, the Ant integration case will help a lot number of people out there.

Best yet, the Teamprise Extensions for Team Foundation Build are available free of charge for everyone - wether or not you are a Teamprise customer.  Also, if you want to see how they work and customize them to meet your own non-standard build system then the source is available under the permissive open source Microsoft Public License (MS-PL).

I would personally like to thank the Team Foundation Build Team (especially Buck Hodges and Aaron Hallberg) who have been incredibly helpful through the development of the build functionality in Teamprise 3.0 while they were also busy working on TFS 2008. 

Hopefully that gives you a quick flavour of Teamprise 3.0 and where we are going with this release.  If you head over to the new site now and take a look at the many improvements we've made, we'd love to hear what you think.

The fantastic team at CodePlex have just rolled out yet another great feature - this time it is statistics for your CodePlex project.  I dropped by my TFS Plug-in for CruiseControl.NET to take a look...

The project is currently averaging over 12 downloads a day and has had nearly 5000 downloads since I moved it to CodePlex in August 2006.  Not bad for a chunk of code I originally wrote on a plane..

This is incredibly motivating as a maintainer of an Open Source project.  I've been knowing that I need to give the CC.NET integration some love as there are a few issues and things that I need to address from the excellent feedback I have been receiving.  However - seeing how many people are still interested in the plug-in despite the excellent CI functionality in the 2008 release of TFS has made me realise that I need to get on this ASAP.  Thanks CodePlex!

Paul Hacker, Mickey Gousset and I have recently started a Team System related podcast called Radio TFS.

While it is not going to win any awards any time soon, we've been having a lot of fun so we are going to continue to try and get one or two episodes out a month. If you have 40 or so minutes to kill, then feel free to take a listen and subscribe.

If you have any suggestions for topic or any questions about Team System that you would like answered then please drop us a line at radiotfs@gmail.com or visit the website at http://www.radiotfs.com.

Developer Developer Developer is coming to the beautiful west of Ireland in May with GAMTUG hosting the event on Saturday May 3rd.  If you are in or around Ireland at that time then I would encourage you sign up.  My good friend, and fellow Team System MVP, Mike Azocar will be doing a session on Scrum which should be well worth sitting in on.

There will be no Microsoft speakers presenting, just speakers from the .NET developer community, although I hear our local friendly Platform Evangelists (DPEs) will be on hand to help out and chat to everyone and to take in the atmosphere.

The day promises to be a great learning experience, but also a fantastic way to meet like-minded people - if anything else, you get a trip to the lovely Galway which is never a wasted journey.

I like my build numbers to be the same number that my assemblies are versioned with (and my end deliverables).  It just makes things easier to track, that way if I get a bug report in from a customer I can look at the version and easily look at the label in source control to see what code that included. In all deliverables provided to the customer, we always output the version obtained from the current assembly somewhere at the start of any diagnostic information, that way you can easily tell what version they are on and instantly track this back.  This all helps to make it easy for bugs to be filed against the correct version and reported in which version they have been fixed (using the nice integration between Team Build and the Work Item tracking portion of TFS).

People are often surprised that this feature does not work "out the box" with Team Build, so I thought I would just take the time to document how I made this work for us internally.  As you'll be able to see, in TFS2008 all the basic hooks are provided for us to support this way of working.

Firstly, our .NET version numbering uses a slightly different scheme to our Java version numbering.  In our Java products, the "build number" portion of the version number is actually the changeset number of TFS at that point in time.  In .NET there are 4 components to a typical assembly version number (1.0.1234.5678) and the maximum value for each number is 65535.  Our production TFS server is currently at changeset 7698 which means that we would get about 6 years out of such a build numbering scheme for .NET - that would be perfectly satisfactory if you had a changeset epoch after each major release (so you would reset the build number to be current changeset - 7698 if we did a major version today).  However Team Build needs a unique name for each build - using a changeset based approach risks having two builds with the same build number.  So rather than do a changeset based system, I decided to make the .NET build numbers be a straight-forward incrementing number. I rely of the default functionality of Team Build to create a label for that build number to track the number back to version control.  The incrementing number value is stored in a file on the default drop location for the build.

Another thing that I should explain is that I don't personally like the "standard" Microsoft way of versioning assemblies as:-

<Major>.<Minor>.<Build>.<Service>

To me, it reads much easier as:-

<Major>.<Minor>.<Service>.<Build>

Where <Build> is the number that increments every time a build is performed.  As far as I am concerned, this difference is mostly cosmetic as it doesn't change the way the CLR resolves the assembly versions, however feel free to correct me in the comments if I am talking rubbish.

So - onto how we accomplish this.  Firstly, in TFS2008 there is a convenient target for you to override to generate your custom build numbers called "BuildNumberOverrideTarget".  The important thing is that each build number must be unique, therefore a good rule of thumb is to use something like BuildDefinitionName_1.0.0.1234.  Inside the BuildNumberOverrideTarget you simply set "BuildNumber" property to be what you want.  Here is ours:-

<PropertyGroup> 
  <VersionMajor>1</VersionMajor> 
  <VersionMinor>0</VersionMinor> 
  <VersionService>0</VersionService> 
  <VersionBuild>0</VersionBuild> 
</PropertyGroup>
<Target Name="BuildNumberOverrideTarget"> 
  <!-- Create a custom build number, matching the assembly version -->      
  <Message Text="Loading last build number from file &quot;$(DropLocation)\buildnumber.txt&quot;" /> 
  <IncrementingNumber NumberFile="$(DropLocation)\buildnumber.txt"> 
    <Output TaskParameter="NextNumber" PropertyName="VersionBuild" /> 
  </IncrementingNumber> 
  <PropertyGroup> 
    <BuildNumber>$(BuildDefinitionName)_$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)</BuildNumber> 
  </PropertyGroup> 
  <Message Text="Build number set to &quot;$(BuildNumber)&quot;" />  
</Target>

The first thing I do is call a quick custom task I wrote that increments the build number stored in the passed file.  I wanted to do this while keeping a lock on the file itself in case two builds tried to update the same file at the same time.  We then take this new number and build the BuildNumber based upon that value.  The code for the Incrementing Number task is very simple and is given below:-

using System; 
using System.IO; 
using Microsoft.Build.Framework; 
using Microsoft.Build.Utilities; 

namespace Teamprise.Tasks 

{ 

    /// <summary> 

    ///   A simple task to increment the number stored in a passed file. 

    /// </summary> 

    public class IncrementingNumber : Task 

    { 

        public override bool Execute() 

        { 

            NextNumber = IncrementNumber(); 

            return true; 

        } 

        public int IncrementNumber() 

        { 

            using (FileStream fs = new FileStream(NumberFile, FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.None)) 

            { 

                StreamReader reader = new StreamReader(fs); 

                long pos = 0; 

                String line = reader.ReadLine(); 

                // Ignore comments in file 

                while (line != null && line.StartsWith("#")) 

                { 

                    pos = pos + line.Length + System.Environment.NewLine.Length; 

                    line = reader.ReadLine(); 

                } 

                int number = -1; 

                if (line != null) 

                { 

                    number = Int32.Parse(line); 

                } 

                NextNumber = number + 1; 

                // Rewind the file stream back to the beginning of the number part. 

                fs.Position = pos; 

                StreamWriter writer = new StreamWriter(fs); 

                writer.WriteLine(NextNumber.ToString()); 

                writer.Flush(); 

                writer.Close(); 

            } 

            return NextNumber; 

        } 

        [Required] 

        public string NumberFile { get; set; } 

        [Output] 

        public int NextNumber { get; set; } 

    } 

}

You compile this code into an assembly of your choice that lives alongside the TFSBuild.proj file in the build configuration folder in source control and is this loaded using the UsingTask call at the begging of your MSBuild project, i.e.

<UsingTask TaskName="Teamprise.Tasks.IncrementingNumber" 
           AssemblyFile="Teamprise.Tasks.dll" />

The next thing that we have to do is to take the new version and force this into the assemblyinfo files.  Personally, I prefer the AssemblyInfo files stored in source control to have a certain well defined number for each release branch (i.e. 1.0.0.0), and make it the build server that versions them.  Some people like to check these back into source control - if you do that, be sure to check them in with the special comment of "***NO_CI***" to ensure that the check-in does not trigger any CI builds potentially putting you into an infinite loop of building.

So, we modify our assembly version files after they have been downloaded from source control using a technique borrowed from Richard Banks, our interpretation of this is given below:-

<ItemGroup> 
  <AssemblyInfoFiles Include="$(SolutionRoot)\**\assemblyinfo.cs" /> 
</ItemGroup>   
<Target Name="AfterGet"> 
  <!-- Update all the assembly info files with generated version info --> 
  <Message Text="Modifying AssemblyInfo files under &quot;$(SolutionRoot)&quot;." /> 
  <Attrib Files="@(AssemblyInfoFiles)" Normal="true" /> 
  <FileUpdate Files="@(AssemblyInfoFiles)"                                 
              Regex="AssemblyVersion\(&quot;.*&quot;\)\]"                 
              ReplacementText="AssemblyVersion(&quot;$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)&quot;)]" /> 
  <FileUpdate Files="@(AssemblyInfoFiles)" 
              Regex="AssemblyFileVersion\(&quot;.*&quot;\)\]" 
              ReplacementText="AssemblyFileVersion(&quot;$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)&quot;)]" /> 
  <Message Text="AssemblyInfo files updated to version &quot;$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)&quot;" /> 
</Target>

As you can see, we are making use of the custom Attrib task that is provided by the essential MSBuild Community Tasks to set the files to read/write and then we are calling the MSBuild Community Task FileUpdate to do a couple of regular expression search replaces on the appropriate parts of the files.

And that's about all that needs to be done.  Now our builds have nice incrementing numbers that have the version number included that is the same as the assembly info files.

One of the most frequent questions I get when talking to people about TFS if how to upgrade from the freely downloadable 90-day TFS 2008 trial to a full version of TFS.  Our TFS 2008 license key arrived at the weekend, so I thought I would take the opportunity to record the process.  The first two steps have nothing to do with installing your license key, just purchasing it - but sadly are often the most complicated.  Installing the actual key once received, is pretty trivial as I hope you will see.

Step 1:  Purchase a TFS License Key.

This step is frequently mis-understood.  You have to pay for the full version of TFS.  Just because you are a partner of an MSDN subscriber, doesn't mean that you get TFS included.  As an MSDN Subscriber, depending on your subscription type you do get access to a 5-user limited version of TFS called "Team Foundation Server Workrgoup Edition".  However only Gold Partners or Partners with an ISV Competency get TFS included in their partner fees - everyone else has to purchase it.  When connecting to TFS, you also need to make sure you have enough Team Foundation Server Client Access Licenses (CAL's) to cover your use - if you have a Team Suite flavor of MSDN then that gives you one CAL.

Step 2: Obtain TFS License Key.

The license key for TFS will be printed on a little sticker on the back of the media that it arrives on.  If it didn't (perhaps because you purchased TFS via a volume licensing agreement) then there are ways around this to get the license key out of the media (look for a file called setup.sdb and open it in Notepad, look for [Product Key], usually at the bottom of the file, and you will find it there).

Because getting a TFS License Key usually involves the physical delivery of the media, you should make sure that you factor this time into your purchasing decision.  If (like most people) your purchasing process takes longer than you budgeted for - then you do have the ability to extend your TFS Trial by an additional 30-days.

Step 3: Enter TFS Maintanence Mode

Go to, Control Panel, Add Remove Programs.

Then find Microsoft Visual Studio 2008 Team Foundation Server in the list and press Change/Remove

Step 4: Enter the Full Key for TFS

At the bottom of the maintenance dialog, you have the option to enter your full license key. 

Note that there was a bug in the RTM version of TFS 2008 that means that workgroup edition doesn't have the ability - see this post for details.  This is TFS 2008 90-day trial, so it works just fine for us.

Enter your license key and press Next.  Note that this will install the license key and fire up a command window for a few seconds while it restarts IIS for the TFS server.  Once you are finished, you will get the following dialog.

And you are complete.  If you really want to check that the new license key has taken hold, then you can fire up a copy of Brian Harry's VersionDetection tool to set your mind at rest.

And there you go - running the final release (9.0.21022.8) with no expiry date :-)

In a previous post, I talked about how Windows file sharing sucks over the WAN. This is particularly annoying for me when trying to view the log of a TFS Build - especially if that build has failed and I want to know why in a hurry. On my computer (sitting on the end of a VPN nearly 4000 miles from my TFS instance), there is a delay of about 50-70 seconds to view the log file depending on the size and the speed of the link at that moment in time.  During that time, Visual Studio is hanging waiting for the file to open.  The issue is compounded by the fact that the rest of the Team Build UI - and in fact the whole of TFS access in general - is so speedy over the same VPN link, that I really notice the time delay accessing build logs.

Therefore - it didn't take too many 70-seconds delays for me to fire up a second instance of Visual Studio to create a work-around.  In Visual Studio 2008 (and in the upcoming Teamprise 3.0 Team Build integration), if the log location provided is not a UNC style path (i.e. \\server\drop\build\BuildLog.txt) but a http:// address, then it will open the file in a browser instead.  Accessing the build log over http helps in two important ways.

1. HTTP is much less latency sensitive than accessing a file from a Windows share
2. A browser will display the contents of the file before it has finished loading.  When accessing the build log directly from a file share, the application (i.e. Notepad) will have to wait until it has recieved the whole file before displaying any of it to you.  These log files can get large - so the improvement in perceived speed is significant. (http:// urls are a lot more cross-platform friendly than UNC paths as well, which is nice for us Teamprise folks).

Therefore, I created  a quick and dirty ASP.NET page that accessing the build log for a particular build over the network and streams the contents of a build log to the browser.  I then add a target into my TFSBuild.proj file that sets the log location to be the http url rather than the default UNC address.

LogView ASP.NET Page

I am by no means an ASP.NET expert - so please feel free to highlight any glaring stupidity on my part if you know better.  I know the code below is sub-optimal and presents some security considerations, however it is a quick work-around that I spent a couple of minutes over to solve my issue - so please treat this code as just that.

Create a new Web Application Project, with references to Microsoft.TeamFoundation.Client and Microsoft.TeamFoundation.Build.Client assemblies.  Create a new aspx page - mine is called view.aspx.  In the page mark-up, ensure it only contains the Page tag, and an output caching directive.  Mine (which is in a C# project) looks like this.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="view.aspx.cs" Inherits="LogViewer._Default" %>
<%@ OutputCache Duration="2592000" Location="Server" VaryByParam="*" %>

Now - the work is performed in the code behind.  

  1 using System;
  2 using System.IO;
  3 using Microsoft.TeamFoundation.Build.Client;
  4 using Microsoft.TeamFoundation.Build.Common;
  5 using Microsoft.TeamFoundation.Client;
  6 
  7 namespace LogViewer
  8 {
  9     public partial class _Default : System.Web.UI.Page
 10     {
 11         protected void Page_Load(object sender, EventArgs e)
 12         {
 13             Response.Write("<html>");
 14             string teamFoundationServerUrl = Request.Params["TeamFoundationServerUrl"];
 15             string buildUri = Request.Params["BuildUri"];
 16 
 17             if (String.IsNullOrEmpty(teamFoundationServerUrl))
 18             {
 19                 teamFoundationServerUrl = "http://localhost:8080";
 20             }
 21 
 22             if (String.IsNullOrEmpty(buildUri))
 23             {
 24                 Response.Write("<title>LogViewer Error</title><body>A valid BuildUri must be passed</body></html>");
 25                 Response.End();
 26                 return;
 27             }
 28 
 29             TeamFoundationServer tfs = new TeamFoundationServer(teamFoundationServerUrl);
 30             IBuildServer buildServer = (IBuildServer) tfs.GetService(typeof(IBuildServer));
 31 
 32             IBuildDetail buildDetail = buildServer.GetBuild(new Uri(buildUri));
 33 
 34             String logFile = Path.Combine(buildDetail.DropLocation, BuildConstants.BuildLogFileName);
 35 
 36             Response.Write("<title>Build Log: " + buildDetail.BuildNumber + "</title><body>\r\n<pre>");
 37 
 38             StreamReader reader = File.OpenText(logFile);
 39             String line = reader.ReadLine();
 40             
 41             while(line != null)
 42             {
 43                 WriteLine(line);
 44                 line = reader.ReadLine();
 45             }
 46             reader.Close();
 47             
 48             Response.Write("</pre></html>");
 49 
 50             Response.End();
 51             
 52         }
 53 
 54         private void WriteLine(string line)
 55         {
 56             line = Server.HtmlEncode(line);
 57             if (line.StartsWith("Target &quot;"))
 58             {
 59                 line = "<strong>" + line + "</strong>";
 60             }
 61             Response.Write(line);
 62             Response.Write("\r\n");
 63         }
 64     }
 65 }
 66 

As you can see - this is a very quick and dirty example.  I am relying on the output caching of the ASP.NET page to provide any performance at all, and this code could be improved in many ways.  However to walk you through the code;

I start by checking for a TeamFoundationServerUrl parameter, if not passed, I assume that this application is being installed on the TFS server itself so localhost:8080 will get me there. I show an error if the BuildUri is not passed.  Inside the TFSBuild.proj file execution, the MSBuild properties $(TeamFoundationServerUrl) and $(BuildUri) are accessible and provide you all you need to be able to get how of the build that you are building.

Line 29 is me getting hold of the TFS instance, line 30 the build server and finally line 32 the build that I am currently executing.  3 lines to get everything I need to be able to query and modify the build information - you gotta love the TFS2008 build API ;-)

I then (line 34) get the build log path, which is always a file called BuildLog.txt in the drop folder.  I then simply stream the file, line by line, into the response stream.

The WriteLine method is used to do this so that I can optionally do a bit of formatting to the lines as I stream them to the client.  In this example, I am highlighting and lines that are the beginnings of a Target - just to make the log easier to read.

I then deploy this ASP.NET page onto an IIS server.  In my case, I have it running on my production TFS server as a separate application (on a different port) and I have the application set to run as a defined user that has read access to the drop share along with read access to the TFS Build Store.  This means that anyone inside the network can anonymously access the web page and view the build log of any build - but that is acceptable in my organization.  You might want to make access more secure - but then you will also have to be cleverer in your output caching decisions.

TFSBuild.proj File Customization

In the TFSBuild.proj file, I then override one of the provided hook targets to set the log location property of the build.  I'm still un-decided as to which is the best target to put this in, but at the moment I'm going with BeforeGet.

As you can see - it is pretty low tech, but very effective.  Clicking on the link starts providing me with log output with-in a second.

I actually have the web site running on port 9090 configured to give me directory browsing of the drop location file share (that is also located on the same server).  This means that I can access my drop files using a browser by browsing to http://tfsserver:9090/ - however, you can not update the drop location of the build to be a http:// url.  This is because the drop path is specified (and verified) as a UNC path and several parts of code in the build client API itself assume this.  You could work around this by extending the ASP.NET page mechanism above to provide access to the files in the drop location - perhaps a future project for me ;-)

Rather a lengthy post this one - but I hope it helps someone else out of the same frustrations I was having.  If you've read this far than I guess it was moderately interesting to you :-)

Brian Keller has posted a great interview with Brian Harry about Visual Studio Team System 2008, and a lot of detail on the improvements in Team Foundation Server 2008.  One of the things that I enjoy about talking with Brian Harry is that you get the information in a direct and clear way, with a complete absence of "marketing speak" or buzzword bingo.  At just over 10 minutes in length, this interview is a classic example of that and is densely packed with information - highly recommended.

I connect to the central Teamprise TFS instance over a VPN connection to the head office in Champaign, IL.  It is a direct distance of nearly 4,000 miles - but probably much longer depending what route my packets take - on a good day typical ping times for me are ~150ms, but bandwidth is also a major issue.  On my current ADSL line (that is booked in for upgrade before the end of the month) I get 140 kbs upstream and about 400 kbs downstream - on a good day.  On a bad day, it can be much worse.  Last year someone decided to start shooting at bits of fibre optic cable in Ohio and that really messed up my day.

In many ways, the fact that Teamprise has a couple of the core development team working remotely over the VPN is good for Teamprise the product because we certainly complain if we encounter any performance issues during dogfooding - issues that the folks in the office with a gigabit connection to the TFS server might not feel as strong about :-)

TFS mostly works great for me over my VPN connection.  The TFS team did a lot of work to optimise TFS traffic for WAN environments, such as use of standard web based protocols for transport, the heavy use of compression, minimization of the SOAP payload, keeping connections cached and not to forget things like inventing the TFS Proxy Server - you can certainly tell that TFS was designed with this type of environment in mind.  (I'm sure it helps that the majority of the TFS team are based in Raleigh, NC while their dogfood TFS instance is based in Redmond, WA ;-) ).   The only times where I have issues are on the rare occasion when Windows File Shares are used or the client needs to query Active Directory information.

Obviously - Windows file shares are an issue for Teamprise in general (with around 50% of the team using non-Windows systems as their primary machine).  But most modern operating systems can talk to CIFS based file systems pretty well.  The issue for me is that Windows file shares suck over a high-latency, low bandwidth connection.  This was one of the reasons VSS performed so badly over a WAN.  Thankfully there are only a couple of main areas in Team System and TFS where Windows file sharing is currently used:-

1. Publishing of test results from the client
2. Accessing the TFS build drop location (and most annoyingly, the build log file).

Note, it because of these types of issues (and the Active Directory releated ones) that I always recommend people connecting into TFS remotely use a VPN if they want access to the full functionality.  While the Windows file sharing bits may perform really badly - at least they will work over a VPN.  Try getting file sharing to work securely between firewalls if TFS is exposed on the internet and a VPN is not used...

In a follow up post, I'm going to be talking about how to modify your builds to make them easier to work with over a WAN / VPN.  Despite these minor niggles (which don't come up very often), if you are considering using TFS for use over a VPN or Wide Area Network then I would certainly recommend it.

Microsoft Team Foundation Server 2008 has a great new improved build system (often referred to as "Team Build").  An advantage of running your build from Team Build is that (by default) all changes between your current build and the last good one are reported in the build report and any work items that were associated with those changesets are automatically updated with the build number they were fixed in.

However, when demonstrating this feature - the following thing always catches me out and is important to remember when using Team Build in production.  The very first time you run a build, it does not associate that build with changesets or update any work items.

Therefore, the first time your create a new build definition you should manually run a build and make sure it is successful. 

In fact I would recommend you do this anyway, even if the changeset association thing wasn't the case, after all you need to test that the new build definition you created actually works!

The reason why Team Build 2008 works in this way is that when Team Build successfully completes a build it stores the label applied to that last good build.  The next time it runs a build that is successful it will compare the two labels to detect which changesets were included in the build.  It will then look over those changesets for any associated work items and update them to include the build number in which they were fixed.

This tip is also true if you upgrade from TFS2005 to TFS2008.  Once the upgrade is complete you should run your builds once manually to check that they are all still working fine and to give a baseline from which changes can be detected.

I just noticed that on Wednesday January 16th at 5pm, the Minnesota Visual Studio Team System User Group are having a talk by Mac Noland.

Mac is a good guy with some very interesting real-life experience in the use of TFS, and I would expect this talk from Mac to give people a great understanding of TFS could fit in their enterprise - but also a realistic, unbiased, warts and all view of TFS with Teamprise in the real world. 

Should be fun - I wish I was closer as I would love to attend myself.  If you are in the area and can make it along, then here are the details:-

Date / Time: Wednesday, Janurary 16th @ 5pm

Where: Microsoft, 8300 Norman Center Dr., Suite 950, Bloomington, MN 55437

Topic: Thomson's use of Team Foundation Server with Teamprise as a cross platform, integrated Configuration Management solution.

Description:

Thomson's Online Services is responsible for the backend storage and retrieval of online assets.  The Online Services - Quality department has implemented Team Foundation Server (TFS) for the group, which primarily develops in Java on Windows, Linux, Linux64, Unix and Mac.  With the help of Teamprise, Online Services is now able to interact with their configuration management solution (i.e. TFS) from non-Windows environments. 

Online Services has learned some valuable "cross platform" lessons while implementing TFS.  These lessons may benefit others as they start to implement TFS for non-Microsoft development groups.  A sampling of their experience is below.

• Yes, you can use TFS to store non-Microsoft software assets
• Replace multiple bug, change, source management tools with TFS
• Use Team Build for non-Microsoft builds

It's funny, in these days of digital distribution, but seeing some physical media for a software project you have been closely involved with still means a great deal. 

Today my January MSDN shipment arrived in the mail - and lo and behold in included a proper physical DVD for Visual Studio 2008 Team System Team Suite.  While it isn't as exciting as a full retail box - it still brought a smile to my face on a foggy morning (sad, I know).

Looks like the folks in the DVD plant have been busy over the holidays.  Congratulations to the Team, lovely to have a real DVD in my hand.

No - this is not a post about the big news in Northern Ireland this past week.  On Friday night I was in the middle of a rather large change that I wasn't ready to check-in to the mainline of code.  However, as I am now in the habit of doing, I shelved the changes to TFS before I stopped work for the evening.  Shelving is a neat feature in Team Foundation Server.  It lets you save your files onto the server without committing the change into the mainline of code.

Over the weekend, my main development machine decided to die on me pretty badly.  It wouldn't even get as far as the BIOS screen - despite plenty of power getting to the motherboard.  An hour long conversation with the friendly technician resulting if nothing more than my knees getting a little dusty and so the machine is now in a box on the way back to the manufacturer.  However, I was able to un-shelve the changes from Friday night onto my laptop and carry on working were I left off with no code loss.

Needless to say - this morning I became a very big fan of shelving:-)

As a follow up to my post back in August when we put TFS Beta 2 onto our production box, I just thought I'd mention that here at Teamprise we have now been running Visual Studio Team Foundation Server 2008 for over 6 months now.  We recently upgraded our production TFS instance to the RTM release of TFS 2008 and everything is going very well.

The Microsoft team have done a fantastic job with compatibility which meant that we didn't even need to re-compile Teamprise to get it to work with TFS 2008 and still get all the performance benefits from the server.  The current public versions of Teamprise work great with TFS2008, as does Visual Studio 2005.

While TFS performance has improved since the RTM of TFS 2005, for me the single biggest reason to upgrade to TFS 2008 are the new and much improved build capabilities.  As you might have guessed by the number of Team Build related posts on my blog lately - in the next version of Teamprise we will be including integration with Team Build.  This has been my area of focus for most of this year so I am really excited to see what people think once we make it available.

In the meantime, if folks are considering upgrading to TFS2008 from TFS2005 then I would certainly recommend it.  The upgrade from TFS2005 to TFS2008 has been very smooth in my experience.

Update: With Teamprise 3.0 we included this work into the freely downloadable Teamprise Extensions for Team Build. The source is also provided under the MS-PL if you are interested. You should definately look at the new version as it contains some fixes and additional features based on feedback during beta testing.

Original Post:

With the recent release of Microsoft Visual Studio 2008 Team Foundation Server we are seeing more and more people looking to use the build capabilities of TFS (often referred to as "Team Build") to manage their Java based builds as well as their .NET ones.  We have an MSBuild task available internally that we use to trigger Ant based builds and report the progress back into TFS, and I wanted to share this with a wider audience to get some feeedback.  This task is heavily influenced by Aaron Hallberg's Team Build DevEnv task which I encourage you to go look at if you are interested in getting other build systems integration with Team Build.

You can download an early version of the Ant task from here - (TeampriseBuildExtensions 1.1MB).  There are two versions of the task included in the zip file - one for TFS2005 and one for TFS2008.  Additionally there is a draft set of instructions included on how to get this working today.  We hope to make the process much easier with future releases of Teamprise.

The Ant task works by calling Java to run Ant. The task first parses the Ant file to locate the name of the project and the description. It then calls Ant and the resulting output from Ant is then parsed by the task to look for key information (such as javac and junit tasks) as well as to pass the results into the MSBuild log. Options which are normally available via ant launching script are available as additional attributes to the Ant task.

Example Usage

<Ant TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
  BuildFile="$(SolutionRoot)\java\HelloWorld\build.xml" 
  BuildUri="$(BuildUri)" 
  AntHome="$(ANT_HOME)" 
  JavaHome="$(JAVA_HOME)" 
  Flavor="%(ConfigurationToBuild.FlavorToBuild)" 
  Platform="%(ConfigurationToBuild.PlatformToBuild)"   
  Properties="BinariesRoot=$(BinariesRoot);BuildNumber=$(BuildNumber);SourceGetVersion=$(SourceGetVersion)" />

Task Reference

The following is a complete list of all the attributes supported by the task, note that many of them are best left to the default values unless a different behavior is explicitly required. Items that are in bold are the ones that are frequently used.