Sid Forcier's Dev Blog Just another Dev Blog

Continuous integration using Team Build 2010 and SVN

I recently had this problem...

We have a multi-project solution that includes not just software, but also hardware and firmware. We'd like to use TFS 2010 as the system of record for everything, and perhaps even have it build the firmware. The difficulty is that the firmware product is built by a Linux server, the team has been using SVN for a long time, and it's not really an option to change their workflow *at all*.

I managed to get a build working in Linux pretty easily using Putty (which is another topic for discussion). Once the build was in place it was a matter of integrating with SVN to cause the build to be kicked off upon checkin.

The rough sketch of my approach was this:

1. Create a web application with one page "BuildStarter.aspx" which accepted one querystring variable "bid"
2. Make that page kick off a build with a build name that matches the querystring variable "bid"
3. Add a post-commit hook into SVN which performs a wget to "BuildStarter.aspx?bid=[BuildName]"

If I get around to it, I'll post the code for the implementation of kicking off a build from the querystring variable, but for now I'll leave that to you. If you've never written anything that uses the Team Build assemblies, Google should prove useful.

Team Build 2010: Reference Hint Paths – Part 2 (No Assembly Required)

In Part 1 I mentioned the MSBuild Arguments build definition parameter and how you can use it to give MSBuild some hints on where/how to resolve references. The problem was that it doesn't support relative pathing. Let's work around that by modifying the build process template to support using the source control path.

Check the reference assemblies into source control

Checking third party assemblies into source control is generally a good idea. In fact, by simply checking your assemblies into source control and updating the references in your projects to use this location you may even resolve your issue.

Add an argument to your build template

I assume you know how to modify a build process template and are familiar with adding variables and arguments. If you're not read this first.

1. Add an argument ServerReferencePath which is an array of strings to hold all the source control paths you'd like to use as reference hint paths.
2. Use the Metadata property to expose the argument to the end user.
   

Build the command line argument

You can do this however you want, but the idea is to build a command line parameter similar to:

/p:ReferencePath="c:\BuildAgentPath\foo\x;c:\BuildAgentPath\bar\y"

and append it to the MSBuildArguments argument. You must do this after the workspace has been created because this approach uses source control and the workspace.

1. In, or after, the Initialize Workspace sequence, add an Assign activity.
2. Set the left side to MSBuildArguments.
3. Set the right side to:If(ServerReferencePath.Length > 0, _
   MSBuildArguments + _
   String.Format(" /p:ReferencePath=""{0}""", _
   String.Join(";", _
   ServerReferencePath.Select(Function(s) Workspace.GetLocalItemForServerItem(s)))), _
   MSBuildArguments)
   

This code really only does one thing of interest. Pay attention to the statement Workspace.GetLocalItemForServerItem(s). This statement converts the server paths you provided to local paths for the build agent currently executing the build request. The rest of the code is just syntactic sugar to get this into a single assignment activity. You're more than welcome, if not encouraged, to split this into a few different activities to handle: the condition where no server reference paths are provided, and to iterate over the server reference paths in a more readable fashion.

What's Next?

That's pretty much it. By setting the MSBuildArguments argument the build will automatically pass that info to MSBuild via the command line.

I may do a Part 3 for this series which would include the ability to use server paths which exist outside the workspace of the build definition.

Team Build 2010: Allow parameter modification when queuing a build

If you have modified a build process template and are exposing an argument via the Metadata process parameter collection (that is, you're making it show up on the Parameter tab when the build definition is modified) and it's not showing up when new builds are being queued, you can add it by following these steps:

1. Open the build process template.
2. Click Arguments in the designer.
3. Click "..." to access metadata.
   
    
4. Change "View this Parameter When" to "Always show the Parameter"
   

Team Build 2010: Reference Hint Path – Part 1 (The old fashioned way)

To specify additional reference hint paths for Team Build 2008 you can simply use the ReferencePath parameter for MSBuild 3.5:

/p:ReferencePath="c:\foo\release;c:\bar\release"

MSBuild 4.0 didn't change this, but Team Build 2010 abstracted it a little. Under the Advanced category of a Build Definition's parameters, there's a field called MSBuild Arguments. You can pass whatever you want here, and it will behave the same as the parameters text box in Team Build 2008. So all you need to do is set your ReferencePath parameter like the example above, and you're good to go.

But there's a problem with this... relative paths aren't supported. In part two I'll come up with a way to work around this issue.

Team Build 2010: “Installing” an Assembly

Here's how to get Team Build 2010 to notice an assembly:

1. Make sure the assembly has at least one Workflow Activity in it. If you didn't write the assembly, this shouldn't be a problem.
2. Check the assembly in to source control.
3. In Team Explorer, right click "Buids" and choose "Manage Build Controllers..."
4. Choose your Build Controller and click "Properties"
5. Set "Version control path to custom assemblies:" to the path from step 2.
6. Click "Ok"
7. Click "Close"