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
- 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 v188.8.131.52
- 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)
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
- log on as the service account
- Open a visual studio command prompt and navigate to the directory the key is stored in
- Type command sn –i XYZ.pfx VSKEY 3645476ACDE0CD2A
- Ensure that you use the key name appearing in the error message!
- When prompted for a password type the password for the pfx file
- Navigate to the same directory in explorer, right-click on XYZ.pfx and select install
- 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
- 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)
- open the Microsoft.VisualStudio.Tools.Office.targets file
- replace all 10.0.0.0 with 184.108.40.206
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.