Want a headless build server for SSDT without installing Visual Studio? You’re out of luck!

An issue that regularly seems to rear its head on my travels is that of headless build servers for SSDT. What does that mean exactly? Let me give you my interpretation of it.

A SQL Server Data Tools (SSDT) project incorporates a build process that will basically parse all of the files within the project and spit out a .dacpac file. Where an organisation employs a Continuous Integration process they will likely want to automate the building of that dacpac whenever someone commits a change to the source control repository. In order to do that the organisation will use a build server (e.g. TFS, TeamCity, Jenkins) and hence that build server requires all the pre-requisite software that understands how to build an SSDT project.

The simplest way to install all of those pre-requisites is to install SSDT itself however a lot of folks don’t like that approach because it installs a lot unnecessary components on there, not least Visual Studio itself. Those folks (of which i am one) are of the opinion that it should be unnecessary to install a heavyweight GUI in order to simply get a few software components required to do something that inherently doesn’t even need a GUI. The phrase “headless build server” is often used to describe a build server that doesn’t contain any heavyweight GUI tools such as Visual Studio and is a desirable state for a build server.

Frankly however going through these steps is a royal PITA and folks like myself have longed for Microsoft to support headless build support for SSDT by providing a distributable installer that installs only the pre-requisites for building SSDT projects. Yesterday in MSDN forum thread Building a VS2013 headless build server - it's sooo hard Mike Hingley complained about this very thing and it prompted a response from Kevin Cunnane from the SSDT product team:

The official recommendation from the TFS / Visual Studio team is to install the version of Visual Studio you use on the build machine.

I, like many others, would rather not have to install full blown Visual Studio and so I asked:

Is there any chance you'll ever support any of these scenarios:

Installation of all build/deploy pre-requisites without installing the VS shell?

TFS shipping with all of the pre-requisites for doing SSDT project build/deploys

3rd party build servers (e.g. TeamCity) shipping with all of the requisites for doing SSDT project build/deploys

I have to say that the lack of a single installer containing all the pre-requisites for SSDT build/deploy puzzles me. Surely the DacFX installer would be a perfect vehicle for that?

Kevin replied again:

The answer is no for all 3 scenarios. We looked into this issue, discussed it with the Visual Studio / TFS team, and in the end agreed to go with their latest guidance which is to install Visual Studio (e.g. VS2013 Express for Web) on the build machine. This is how Visual Studio Online is doing it and it's the approach recommended for customers setting up their own TFS build servers. I would hope this is compatible with 3rd party build servers but have not verified whether this works with TeamCity etc.

Note that DacFx MSI isn't a suitable release vehicle for this as we don't want to include Visual Studio/MSBuild dependencies in that package. It's meant to just include the core DacFx DLLs used by SSMS, SqlPackage.exe on the command line, etc.

What this means is we won't be providing a separate MSI installer or nuget package with just the necessary build DLLs you need to run your build and tests. If someone wanted to create a script that generated a nuget package based on our DLLs and targets files, then release that somewhere on the web for easier integration with 3rd party build servers we've no problem with that.

Again, here’s the link to the thread and its worth reading in its entirety if this is something that interests you.

So there you have it. Microsoft will not be be providing support for headless build servers for SSDT but if someone in the community wants to go ahead and roll their own, go right ahead.

Comment Notification

Comments

Thanks for the update on this, Jamie. I'd tried doing a headless install and just gave up. I let the installer add the VS IDE in order to get everything working properly on our Jenkins boxes because it was a lot easier than trying to get the headless install working. It takes up extra space, but we have that much to spare and just don't use it once installed.

This is a massive oversight for SSDT projects. I've recently started a new project and promoted the usage of SSDT projects (over liquibase). This is costing me a lot of time to implement a new build process on a clients build server. Such a shame as SSDT is awesome and solves some problems with deploying integration tests with database teardown and pre/post deployment scripts etc..

If MS are telling you to use visual studio installs to do it, what exactly is your problem? Visual studio is an application. It's not going to do you any harm having it installed on your build server unless you open it and leave it running. It gives you all the components you need. It's how Microsoft do it too. Yes I understand the argument about unnecessary components but the interdependency issue MS are telling you about is worth bearing in mind. Stop being such purists and just accept the fact that your tools still knock the socks off anything the java camp has! Do you honestly want to start using ant and maven? I have and they are nothing but a painful mess.

Thanks for the article Jamie, I have a similar issue I'm hoping the extensive research you've done could help.

My issue's not the Build Server (we installed VS2013) our issue's the SQL Server, we run SQL Server 2008r2 (no choice) but we need a better version of SSDT (or sqlpackage.exe) than that version ships with...

so, we do a headless install of SSDT 2012 on our SQL Server using the following:

Newer versions of SSDT contains functionality that our product depends on (composite projects I think is one such feature). Everything publishes nicely on our dev systems, but if a customer has a 2012 deployment, then all heck breaks loose.

We cannot ask the customers to submit their 2012 databases and upgrade these manually. That is a no-go.

Luckily we usually host our customers' databases, and 2014 has so far published our dacpacs without fail. This leaves a handful customers in the dark unless they upgrade to 2014.

I'm unable to build a CI pipeline for SQL Server BI projects hosted in Azure IaaS because the MSBuild used within VSTS can't seem to handle SSSDT project types.

I can get builds of other VSTS project types working and can Release them into IaaS VM's, so I know the back of the pipeline can be achieved, but with 100+ enterprise BI projects need that SSDT support in the VSTS MSBuild (or at least knowledge how to make it happen).

Annoying thing is that the Build doesn't actually even need to do anything (ie compile to a DLL) the solution's deployable artefacts.

So tantalizingly close to making an epic transition to full cloud for our full BI stack, and yet so far.

Let me just clarify something. This article talks about SSDT, and by that I mean database projects, not SSIS/SSAS/SSRS. Your comment says " but with 100+ enterprise BI projects need that SSDT" which leads me to assume that you are referring to building SSIS/SSAs/SSRS projects. is my assumption correct?