Building a VS2013 headless build server - it's sooo hard


  • I have for the last 4 hours been trying to build a build server to allow our continuous integration server to build our project, now newly migrated to .net 4.5.2.

    I seem to be installing and re-installing what looks like the same files over and over, and I'm getting somewhat bored of this.  I understand that I might be able to do this easier by installing a full VS build environment.  Is that the case?  Are there any licence restrictions? I mean - I'm obviously not going to pay for Ulitmate for a build server - but at the same time i probably can't use Express (this is a commercial build).

    Seems to me that integrating SSDT into Visual Studio means that to do a build means I have to have VS installed-  is that right?

    This is all rather confusing - if only there was some sort of dependency tool that we could use - any chance of a "Nuget for software" type thing?


    Mike Hingley

    Wednesday, August 06, 2014 1:20 PM

All replies

  • As a compromise, you could install SSDT from the ISO.  It won't be a full VS install, but it will still have the VS shell with SSDT and build components.

    I've installed SSDT build support without Visual Studio or the VS shell, but it was painful and ultimately not worth it.  Even the SSDT MSBuild files look at the registry for your Visual Studio installation path information (see Microsoft.Data.Tools.Schema.SqlTasks.targets), so that's the kind of stuff you end up having to work around.

    Wednesday, August 06, 2014 5:08 PM
  • We've just put up a whitepaper and presentation slide deck on the blog covering this exact scenario.

    The official recommendation from the TFS / Visual Studio team is to install the version of Visual Studio you use on the build machine. For SQL projects you can install the SSDT for VS2012 on that build server per uniquedisplaynameformypublicprofile's suggestion, or you can install VS2013 Express for Web, which provides full support for building SQL projects and most other project types (C#, unit test, Web app projects).



    Wednesday, August 06, 2014 5:30 PM
  • Hi Kevin,

    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?


    Thursday, August 07, 2014 8:16 AM
  • Hi Jamie. 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. We've even added support  in the latest project definition for overriding the path to the targets file using  $(SQLDBExtensionsRefPath) and to the reference DLLs using  $(SSDTPath) However we are not going to take on the release and maintenance of this ourselves as it conflicts with current TFS best practices. 


    Thursday, August 07, 2014 9:05 PM
  • Hi Kevin,

    Thanks for the answer. I suspect it won't surprise you to know that this is rather disappointing. The notion of having to install full-blown VS (even if it is just Express) on a build server gives me that knotty feeling in my stomach - you know it *can* be done but it inherently feels like the wrong thing to do. The phrase "Sledgehammer to crack a nut" springs to mind.

    Appreciate the response anyway.


    Friday, August 08, 2014 8:59 AM
  • As a developer, the given solution has a "code smell" about it. I try to keep our build server as lean as possible, and this flies against all I've tried to achieve :(
    Thursday, August 14, 2014 2:24 PM
  • Hi Kevin,

    Once we have installed Visual Studio Express on the build agents (50+ in our case), does this mean everytime there is an update to SSDT in Visual Studio we are using for development, we will have to apply the same update to the build agents (e.g. using

    Thanks, Jag
    Friday, September 26, 2014 8:17 AM
  • There is not a strict requirement/need up update every time but we would recommend that you keep the two in sync. It is a good practice given that we add bug fixes in each release and this might cause slight differences in the validation applied to your project (e.g. you might get an unresolved reference error on your build agent that wouldn't repro in the latest bits on box, or we add in a new configuration option that you need applied for correct build/deployment to occur). Having said that, the majority of the time you build agent will continue to work correctly even if users update locally.

    Note that if you're installing on that many agents, an administrative install using powershell with the "/q" or "/passive" flags to avoid user interaction may help make it easier for you. Run ssdtsetup.exe /? for more information about this.


    Friday, September 26, 2014 5:25 PM
  • We need to build for both 2010 and 2012 Visual Studio and possibly 2013 in the near future  do we need all three versions of SSDT installed or are the Target DLLs Downward compatible (giving us just 1 installer to worry about (im guessing not as theres a ver folder in the Error Message when its not there).

    And a licensing question  if all devs have msdn subscription and building is cleary a dev role is it correct that the build servers don't require licensing if only used as build servers?

    Wednesday, June 10, 2015 7:57 AM
  • Hi Colin, we no longer support VS2010 so it's possible you might need to have to use two different versions if you want to continue supporting that. However for VS2012 and 2013 we are definitely compatible and you can choose to use your preferred version on the build server. The only caveat is that you should ensure the build definition has a  VisualStudioVersion value set to match what's installed on the build agent (e.g. if you install VS2012, it should be =11.0, for VS2013 = 12.0).

    Finally in terms of licensing - for VS2012 you can install the SSDT for VS2012 which is 100% free and doesn't require a paid license. For VS2013 you can install VS2013 Express for Web which again doesn't require a paid license and has all the SQL Server Data Tools. I can't comment on licensing requirements for paid SKUs, you would want to contact your support representative if you wish to use one of those, but the solution is to have one of the free, supported versions installed.

    Hope this helps,


    Wednesday, June 10, 2015 4:41 PM