Building with Team Foundation Server

As mentioned previously I’ve been knee deep in Team Foundation Server (TFS) related work, specifically around build and release management. Build automation is usually a pain point so I decided to start there first though I will admit to creating user/group permissions, defining area path/iteration structures and customizing the User Story work item type among other activities prior to this juncture. Setting up the build server’s controller and agents was simple enough however when it came to using Wix, BRDLite and configuring the build definition is where it got interesting.

To set the stage, the basic premise was to have a build run daily (setting multiple definitions for either continuous integration or gated check-in’s is planned for the next phase), create an MSI and drop the files onto a deployment server. This sounded easy enough although there were a few issues that apparently needed to be addressed for this to be a successful scenario.

First and foremost, there are some prerequisites that needed to be installed and/or configured on the build server, especially since Wix and BRDLite was being utilized. Let’s walk through these steps to avoid any confusion:

For Wix, there are two options, 1) install the toolset on the server or 2) modify the "wxs" files (XML) within the project so that it references a generic path (great blog post by Neil Enns which outlines this procedure). I opted for the former as there is only one build server being used but if multiple were required then I’d probably go with the latter.

Since I’m using BRDLite and additional customizations, downloading the TFS Build Extensions was necessary. After unzipping the files and copying them to my local “BuildProcessTemplates” folder, I then added the extensions to the corresponding Source Control folder (e.g. " $/MyProject/BuildProcessTemplates"). Finally, I associated said folder to the Build Controller via the "Version control path to custom assemblies" properties area.

I’ll spare you the details of installation and association of the BRDLite process template to the build definition as the Rangers have a great hands on lab (HOL) just for this procedure (refer to the linked guidance above). Once that was complete it was time to start a build using a test solution I created and see the fruits of my labor.

“Danger Will Robinson! ” Alas, the following error was received and so my early lunch was put off to a late dinner.

While the blog entry in the aforementioned error was nice to see, it unfortunately did not solve the problem. After scouring the ‘Net for a resolution only to find lots of “possible workarounds” I figured I’d cut to the chase and get it straight from the horse’s mouth. I pinged Rob Mensching (Senior Software Development Engineer [SDE] here at Microsoft) and after speaking with him he said there are two ways to solve this issue. 1) Create a domain account for the TFS build service and add it to the local Administrators group or 2) Disable “light’s” VBScript validation. After doing just that, that error went away but regrettably another took its place.

Now the following error was received:

“File not found: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe”

Installing the Windows SDK Components took care of this error as the “signtool” is included in this package.

Alright, so now that everything was installed and configured it was time to queue a new build. Eureka! The build was successful, the files were created in the appropriate drop folders and an MSI package was copied to the deployment server.

Now let’s see what’s on tap for dinner…