3

I'm attempting to build a .sqlproj on a TFS Build Server. I've followed the instructions here:

http://sqlproj.com/index.php/2012/03/headless-msbuild-support-for-ssdt-sqlproj-projects/

which I was directed to from here:

How to build .sqlproj projects on a build server?

But I still cannot build. The error is:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets (441): The "SqlModelResolutionTask" task could not be instantiated from "C:\Program Files (x86)\Common7\IDE\Extensions\Microsoft\SQLDB\Dac\120\Microsoft.Data.Tools.Schema.Tasks.Sql.11.dll". System.TypeInitializationException: The type initializer for 'Microsoft.Data.Tools.Schema.Tasks.Sql.DataTask' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Data.Tools.Schema.Sql, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. at Microsoft.Data.Tools.Schema.Sql.Extensibility.ToolingShim.ConfigureExtensions() --- End of inner exception stack trace --- at Microsoft.Data.Tools.Schema.Tasks.Sql.DataTask..ctor()

The SqlTasks.targets file, used by the SQL project, references this:

C:\Program Files (x86)\Common7\IDE\Extensions\Microsoft\SQLDB\Dac\120\Microsoft.Data.Tools.Schema.Tasks.Sql.11.dll

which in turn references the invalid version mentioned above.

However, the files installed by the process in the link above don't install this version. They do install version 10.3.0.0, which is referenced by

C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\Microsoft.Data.Tools.Schema.Tasks.Sql.12.dll

but this file is not the one used by the .targets file.

I don't know what the numbers at the end of this dll mean, but it seems odd to me that the one ending 12.dll references an earlier version of the one ending 11.dll.

I'm using Visual Studio 2013 and SQL Server 2012 - neither of which are installed on the build server, which I believe is the recommended situation. I don't know what the IDE folder is, or why the .targets file is using it.

I've spent about two days now trying to get this to build, but I'm out of ideas. Anyone know what's going on?

Community
  • 1
  • 1
bornfromanegg
  • 2,826
  • 5
  • 24
  • 40
  • In addition to Just TFS's suggestion below to install VS2013 on your TFS server, note that you may need to manually uninstall SSDT Build Utilities MSI before doing this. There is an issue in that code that incorrectly installs it to C:\Program Files (x86)\Common7\IDE if the required Visual Studio version doesn't exist on disk. It should be installed to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE instead. So first uninstall that MSI, then install the full VS2013 per Just TFS's recommendation – Kevin Cunnane Jul 14 '14 at 23:32

2 Answers2

3

If you are running VS2013 SSDT is built into VS as long as you select it on the install screen. Install VS2013 with SSDT onto your build server. create a build definition and under Process > Build > Advanced Add the following to the MSBuild arguments to build the sql proj

/t:Build

if you have a publish profile and want to test publishing to SQL then add the publish switch and provide the link to the profile file

/t:Publish /p:SqlPublishProfilePath=MyDB.publish.xml.

this will publish the db to the server specified in the publish file.

the publish profile file can be created by opening the project in Visual Studio, right click on the project and select publish. Select save once you are happy with the publish options and then check in the file to source control so the build can find it, (project Root).

Just TFS
  • 4,697
  • 1
  • 18
  • 22
  • 2
    Boo to Microsoft having gaps that require a VS installation on the build server......... – granadaCoder Jul 14 '14 at 21:29
  • @granadaCoder There's no additional licensing cost involved in installing VS on the build agent. The build agent contains just the stuff necessary to run builds, not necessarily the stuff necessary to build anything you can throw at it. TFS can build Java applications -- do you expect Microsoft to include the Java SDK in their build installation? Of course not. – Daniel Mann Jul 14 '14 at 23:14
  • Hi. Is this really the only way? We were trying to avoid having to install VS on the build server, since it kind of defeats the point of having a headless build. – bornfromanegg Jul 15 '14 at 08:04
  • No, but its the cleanest and quickest way, if you are determined then I'm sure if you spend the time and install all of the individual pieces and make sure all of the dependencies are there you could set up a headless build. – Just TFS Jul 15 '14 at 08:14
  • 1
    Well, that *was* my question. According to the blog, it's supposed to be possible. If I can't get it to work, then I will just have to install the whole thing, but I was hoping I'd maybe just missed something in the instructions. Maybe they only work for 2012 or something. – bornfromanegg Jul 15 '14 at 08:21
  • to be honest i struggled with 2012 following those instructions last year,SSDT wasn't built into 2012, but i always have VS installed on my build servers for code coverage anyway so i stayed with what i know works. – Just TFS Jul 15 '14 at 08:24
  • Right - well, that's good to know. We're getting a new build agent built, so I'm going to try again with a clean slate. If it doesn't work first time, I'm just going to bite the bullet and install the whole lot. – bornfromanegg Jul 15 '14 at 11:27
  • Microsoft dependency management is still behind the times compared to Maven. And Nuget/Versions is a tough cookie to crack. This is my opinion, they will vary. – granadaCoder Jul 15 '14 at 13:04
  • Accepted answer because it's the most helpful response, and it does work. It doesn't seem to really answer the question of "How do I get a headless build working", but if the answer is, "You can't", then maybe it does. If you see what I mean. – bornfromanegg Aug 07 '14 at 07:35
0

I was having this issue building a SQL Server project on an Azure DevOps CI/CD pipeline. None of the pre-built build tasks would work for me. And it is not possible to install a VS instance on the build server, I guess.

I solved this by avoiding to add a SQL Server project to the solution.

I achieved this by using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from the set of SQL scripts. By adding this second project to the solution, I managed to continue taking advantage of linking the project to a live database through SQL Server Object Explorer on Visual Studio. I gave a more detailed explanation in this answer.

ccoutinho
  • 3,308
  • 5
  • 39
  • 47