Geeks With Blogs

News
Charles Young

I spent some time (more time than I would have wished) last week getting Team Foundation Server RC1 up and running, and exploiting its Team Build facilities for a development team working on a short (three week) proof of concept.  Things were slower than I would have liked due to a combination of unfamiliarity with the yet-to-be-launched system, unfamiliarity with another MSBuild framework, bits of which we are exploiting, and what appears to be yet another bug in Visual Studio 2005.   However, it is working now, and I am pleased with the results (lots of green on the screen!).   OK, it probably doesn't take too much to impress me as far a automated build is concerned.   Like so many other developers, I bear the scars of many years of struggling with build issues, and almost any toolset that helps to make this burden easier is likely to meet with hysterical joy.  Even so, to have easy access to an MSBuild-based framework integrated into Visual Studio, and directly integrated with source control and other Team Foundation Server facilities is just great.

A few things to be aware of.   As others have blogged, RC1 (and version 1) of TFS does not offer built-in support for build scheduling, despite documentation that explicitly links automated build with the TFSServerScheduler service (see the 'Team Foundation Server Task Scheduler' topic in the administrator's guide).   It's not a big problem.   Use the TFSBuild.exe command line tool with the Windows Task Scheduler to give you what you need.  Great stuff.  You can implement continuous integration so simply.   I've gone overboard, and set up hourly builds.  I left my schedule running over the weekend just for the fun of seeing screen-fulls of green blobs first thing on Monday morning.   Well, it made me feel good!

We are  running TFS in a single server configuration, and running Team Build on a separate build server.  This seems a sensible configuration for smaller development teams.   However DO NOT do what we are doing, and run all this stuff on Virtual Server images!   No, no, no.   TFS is a big beast and needs to eat real hardware for lunch, not virtual hardware competing with other VPCs for the same resources.   The decision to use Virtual Server was not mine, but another time I will kick up a fuss if I find we've been give virtual images rather than the real thing for our dev servers.   Fortunately, my current project is a short and sharp proof-of-concept which won't be generating a large code base, so we should be OK, but it's still taking many minutes to complete a build of not that much at all.

I ran into one problem.  Several of our projects are BizTalk projects, and we have a Visual Studio solution that contains a mixture of BizTalk and other project types.   Team Builds use an entire framework of pre-defined MS-Build targets and tasks to handle the build process.  The fundamental idea is that you need only to reference your solution in the generated TFSBuild.proj file (an MS-Build file) using item elements, and Team Build will handle everything for you.   That's OK, but this approach only works where the project types use MS-Build for their project definitions.   This includes C#, VB.Net and J# projects, but does not include, for example, BizTalk or Setup projects, or C++ project, for that matter.  If your solution contains a mixture of MSBuild and non-MSBuild project types, you cannot use the approach to build the entire solution.   Only those projects that use MSBuild for the project files are built.

The simple answer to this issue is to override the AfterCompile target in your TFSBuild.proj file, and use this to shell out to DevEnv.exe.   We have a solution that contains a number of BizTalk projects and a smaller number of C# 'helper' libraries.  I originally attempted to handle this by adding a number of elements pointing to each of the C# helper projects, and overriding AfterCompile to use DevEnv to compile the BizTalk projects in turn.   This approach failed.   The compiled C# libraries were not placed in the output directory, and the BizTalk projects, which depend on this code, would therefore not compile because their project references could not find the helper code.  The build log showed that the C# compiler issued a warning for each of the helper libraries saying that "The OutputPath property is not set for this project".   Needless to say, the OutputPath project was set for each project, and the warning was clearly spurious.

This problem is probably related to a 'known issue' in Visual Studio 2005.   This issue does not appear to be formally published by Microsoft, but is mentioned by a Microsoft employee at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=205738&SiteID=1.   This is my current working theory, though it doesn't seem to quite stack up.   As described in the forum post, the issue occurs when you build a solution with a project that has a project reference to another project in the same solution, but which is not built as part of the solution.  I'm really doing the opposite.  Team Build is building projects referenced by other projects in the same solution which are not yet built.   Nevertheless, having read the post, I abandoned my initial approach, and ended up simply building the entire solution via DevEnv in AfterCompile.   This works fine.

I ran into another problem which I quickly fixed thanks to a blog by Nagaraju Palla at http://blogs.msdn.com/nagarajp/archive/2005/11/08/490501.aspx.  His blog article is self-explanatory, and lists exactly the error message I got, the reason I got it and the fix.  I won't explain more here, but if your solutions are using password-protected keys for strong naming, you too will get the ResolveKeySource-related "Showing a modal dialog box..." error.

One tip arising from this issue.   When appropriate (e.g., after a developer checks ina bunch of changes), I typically open Visual Studio on the build machine and build the solution manually under the IDE to check that the source will compile.  Don't forget to close Visual Studio before the next Team Build run.   If you use the same approach, consider logging onto the build server using the Team Build service account.   If I had done this from the start, I would probably have never encountered the problem with password-protected keys.   The first time you build under the IDE, you are prompted to enter the password which is then stored against the user's identity in the crypto store.   Testing builds under the Team Build service account in this way is likely to give you earlier visibility of certain problems.

Solutions Build Framework (SBF)

Jed Farr and others from Microsoft UK have written their own MS-Build framework called SBF.   One of the developers on my current project is Thomas Manson who wrote the BizTalk tasks for this framework, and introduced me to SBF.   Good stuff, and I warmly recommend it to you.   You can download the current version from GotDotNet at http://www.gotdotnet.com/codegallery/codegallery.aspx?id=b4d6499f-0020-4771-a305-c156498db75e.   Currently, SBF does not provide support for TFS.   It does support VSS, and also Source Depot which, if you are wondering, is Microsoft's venerable internal source control system.   I am told that an internal release of a TFS-aware version of SBF is imminent, and hopefully this will evolve into a public release on GotDotNet at some point in the future.   In the meantime, I soon worked out that there was little point in trying to get the targets in SBF working alongside Team Build.   The two frameworks currently do not co-exist at all happily at this level.   I initially imported the SBF targets into TFSBuild.proj, but this did not work due to several conflicts.   In the end, I simply imported the SBF tasks (enumerated in a separate MS-Build file) into TFSBuild.proj.   I also added the SBF bin directory straight into source control as a child folder of the Team Build folder.   Each time Team Build runs, it gets the latest version of the Team Build project from source control, having first deleted the entire contents of the local Team Build project folder. Adding the bin folder into source control is an easy way of ensuring that the assemblies are always made available in the correct location.   There is a lot of functionality in the SBF task library, and so far things have worked very smoothly indeed.  For example, I created a target that drops and recreates an IIS virtual directory, provisioning and configuring it as an ASP.NET 2.0 application.   Despite having never used SBF before, and despite rather poor documentation, my target worked first time, except for one minor logical error on my behalf.   Great stuff.

Build is difficult.   To this day, it all too often remains the Cinderella of dev team activities with too little awareness of the importance of properly resourcing this requirement.  Developers, who should be coding, instead spend much of their time struggling to try to achieve and maintain a stable build process, with really damaging consequences to the health of development projects.   Team Build, exploiting MS Build, is a great step forward in the Visual Studio world, and provides a really useful first generation toolset for managing the build process.  There is more that Microsoft could do, and I'm sure future TFS releases will provide additional functionality.   SBF, although not yet integrated with Team Build, provides additional support for easing the build burden.

Posted on Wednesday, March 8, 2006 1:38 PM | Back to top


Comments on this post: Team Foundation Server: Experiences with Team Build

# Experiences with Team Build
Requesting Gravatar...
Charles Young has written a very nice article on his experiences with Team Build and Team Foundation Server.  His summation on software builds is precisely what I’ve been saying years:
“Build is difficult.  To this day, it all too often r...
Left by Steve Hart on Mar 13, 2006 12:23 PM

# re: Team Foundation Server: Experiences with Team Build
Requesting Gravatar...
Its possible to build BizTalk Project with TFSBuild, .btproj, can be build using MSBuild or TFSBuild and DevEnv, Let me know if someone is having issue with it. email me at om.baghel@gmail.com.
Left by Om Baghel on Jun 14, 2006 12:42 PM

# re: Team Foundation Server: Experiences with Team Build
Requesting Gravatar...
Thomas did not write the biztalk libraries for SBF, check your facts.
Left by Fred on Jun 21, 2006 7:51 AM

# re: Team Foundation Server: Experiences with Team Build
Requesting Gravatar...
My apologies if I was wrong. I'll check this with Thomas next time I see him. Who did write them?
Left by Charles Young on Jun 21, 2006 10:38 AM

# re: Team Foundation Server: Experiences with Team Build
Requesting Gravatar...
I have my issue resolved with trouble.
Left by Om Baghel on Jun 22, 2006 5:13 PM

Your comment:
 (will show your gravatar)


Copyright © Charles Young | Powered by: GeeksWithBlogs.net