By Richie Lee

Based on a previous post about TFS Build Server Best Practices,I thought I’d share the stack I install and a few of the steps that I go through to get the build server working. Obviously your experiences will be different to mine, and I don’t recommend that you follow this to the letter unless you have a similar set of solutions to build. I’m also going to assume you have Windows Server installed and your build service up and running, there are plenty of blogs and MSDN articles that show you how to set this up.

To be clear, in our projects, we have the follow solutions to build:

  • VS 2012 Web Solutions
  • VS 2012 Windows Services Solutions
  • SQL Server 2012 Database Solution
  • SQL Server 2012 Reporting Services Solutions
  • SQL Server 2012 Integration Services *
  • SQL Server 2012 Analysis Services
So in order to build this, we need the following stack installed
  • SQL Server 2012 (what to install: Database Engine Services (Full-Text Semantic Extractions) SQL Server Data Tools, Integration Services, Client Tools SDK, management Tools- Basic (Management Tools Complete)
  • VS 2010
  • VS 2010 SP1 (required for SQL Server IDE)
  • VS 2012 Premium and Update 1
  • WiX 3.7
  • Enterprise Library 5.0
  • f# 2.0 redistributable
  • MSBuild Community Tasks
  • TFS PowerTools Dec 2012 Edition v1.4.0.56
  • SSDT Dec 2012 (this is different from the one that you will need to install as part of SQL Server 2012, apparently they are different, if that sounds crazy then you’re right it is)
The order here is very important; if you don’t install SQL Server before Visual Studio SQL Server Express is installed by default. The reason we need VS 2010 here is because you can see we use several BIDS solutions here, which still requires a separate IDE from VS 2012 Premium (yes I know BIDS 2012 is available because the devs are yet to install it and test it I’m not going to change the build servers. This is an important lesson I learned; a dev breaks his box, he’s only affected himself, you break the build server, you affect the whole team, so let the updates filter from the devs to the build server and don’t be a hero!)

We use a service account to run the build service. I always add the service account to the administrators group on the server. Whether this is good practice or not, it’s a little vague, but at least you can get a build server up and running.

We also have a nasty little gotcha w/r/t to strong name assemblies. When we first run a build, we get this error:

“Cannot import the following key file: ........\Security\Certificates\XYZ.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_3645476ACDE0CD2A”

The part in red will be unique to the account that is attempting to compile the dlls. The solution here is to

  1. log on as the service account
  2. Open a visual studio command prompt and navigate to the directory the key is stored in
  3. Type command sn –i XYZ.pfx VSKEY 3645476ACDE0CD2A
  4. Ensure that you use the key name appearing in the error message!
  5. When prompted for a password type the password for the pfx file
  6. Navigate to the same directory in explorer, right-click on XYZ.pfx and select install
  7. You’ll then get a wizard, leave all the settings as is, just ensure that you type in the same password when prompted (3rd screen), then continue with the default options until it’s done
We also have an VS 2010 Excel Add-In project that will fail to compile unless I go to
  1. C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools (If your O/S is x64, the path is “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools)
  2. open the Microsoft.VisualStudio.Tools.Office.targets file
  3. replace all 10.0.0.0 with 11.0.0.0
If any changes are made to the dev machines, then chances are you will need to make it to the build server, so make sure you’re aware of any changes coming upstream: most of our boxes are Windows Server 2012, but those that are not had to have .NET 4.5 installed manually.

You can clearly see from this list that a mature and complex set of solutions requires considerable amount of software for a build server to work. Essentially, whatever is installed on a dev box should also be installed on a TFS build server for it to work. I’ve heard people talk of cherry picking dlls etc, but that is a seriously unrealistic method of creating a build server.

* If you are deploying the new ispac, then you know that MSBuild does not compile this type of project. There are several ways to get it to compile as part of a larger automated build, which I will cover in my next post.