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.

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.

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"
   

/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.

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"