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