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

    Question

  • 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?

    thanks

    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).

    Thanks,

    Kevin


    Wednesday, August 06, 2014 5:30 PM
    Owner
  • 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?

    cheers
    Jamie

    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. 

    Kevin

    Thursday, August 07, 2014 9:05 PM
    Owner
  • 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.

    Regards
    Jamie

    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