Base Team Build Directories Setup

So you want to setup a Build server, sounds easy doesn’t it?  It actually is, just need to account for a few little details, primarily 2 directories, the build working directory and the build drops directory.  The biggest killer of a build server is the infamous MAX_PATH limitation, limiting files on disk to 260 characters or less:

Setup your build working directory. 

You’re build agents need a temporary workspace to build from.  The Build Agent definition has a “Working Directory” setting that is the base for this.  One thing to note is a sources subdirectory is added to that directory you specified, which will go into the overall path length (aka MAX_PATH limitation).  The Work directory field has some interesting macros to use for creation of unique base folders to allow multiple agents to run multiple build definitions on the same box.  As with all thing, THOU SHALL NOT PUT THIS ON THE SYSTEM DRIVE.  A child cries every time either a build directory or the build drops directory is defined on the same drive letter as the OS, most of the time the C drive. 

My preference is to use the numeric ID’s TFS assigns to the build agent and the build definition to segregate these folders.  I will use the D drive as my example non-system drive I use for data.  Make a directory called D:\bld and give full rights to the service account running the agents on that machine:

Working Directory = D:\bld\$(BuildAgentId)\$(BuildDefinitionId)

What you will see = D:\bld\5\3  (the 5th build agent building the 3rd definition)

Setup your build drops directory and share.

Sometimes this is on your build machine, sometimes its on file server.  The key is this needs to be a file share where the full UNC is in the build definitions.  The key thing to remember is the build service account needs full rights both the file system where the share exists and the network share (thru Advanced Settings on the sharing dialog).

How to build Visual Studio 2010 Extensions thru 64bit Team Build

There has been a lot of great things added to Visual Studio 2010, specifically around creating custom Add-in/Extensions/Tool Windows/etc..  You download the Visual Studio 2010 SDK and off you go enhancing your development experience.

The one challenge I’ve had is trying to get these extensions to build thru Team Build 2010.  First few times I didn’t really bother with it to much, just chalked it up to something strange in the way the SDK does the packaging.

I started to dig into it and hit this little article.  So I logged onto my build box, opened a Visual Studio 2010 Command prompt, and it built from my command prompt.  Hmmm interesting.

Then my friend, the “where” command, tells me I’m running the 32bit version of MSBuild.  Of course since the default Visual Studio 2010 Command Prompt sets you up with the 32bit environment variables.  Makes sense.  DevEnv (Visual Studio main program) is also currently only 32bit.

So as an experiment, since the builds I’m doing don’t require to compile for x64, I found where to tell Team Build to use the 32bit version of MSBuild instead of defaulting to the version of the host process (aka 32bit for Visual Studio and CMD.EXE, 64bit for Team Build).

Open up your Build Workflow in Visual Studio and:

• Open Sequence
• Open Run On Agent
• Open Sequence
• Open Compile, Test
• Open Try Compile and Test
• Open Compile and Test
• Open For Each Configuration….
• Open Compile and Test….
• Open For Each Project in BuildSettings.ProjectsToBuild
• Open Try To Compile the Project

You should see something like this:

Right Mouse click on “Run MSBuild for Project”

Change the ToolPath variable to the 32bit directory for .Net (C:\Windows\Microsoft.NET\Framework\v4.0.30319 for example).

And your off!