Share via

Changes to SSDT and SqlPackage.exe installation and updates

  • Article

A major benefit of the new SQL Server is that you don't need to wait years to get new features. Azure SQL DB is adding features on a frequent basis and the tools you use need to keep up with this. The old model of globally shared dependencies with GAC (Global Assembly Cache) made this very difficult to maintain for tools. We're in the process of moving to a new, faster update model without the worry of breaking other applications that are already installed. This month's release has the first set of changes, and the information below will give useful information on what you can expect to change.

What does this mean to you

Mostly, this means that if you update your tools you can safely do so without worrying about breaking other components. SSDT updates should not break SSMS or the SQL Server engine. For the relational database tools in particular, we will not ship any updates that overwrite components shared with SSMS or the engine. We're moving these components out of the GAC and out of shared install directories - more components will be updated in this way with each release.

Note:  SSIS updates will continue using the engine servicing releases (CU1, CU2) for the immediate future. If you select to install this please be aware that it will follow the traditional global assembly sharing model.

For users of the next version of Visual Studio, expect to see far fewer "SQL Server" entries in Add/Remove Programs. We now package more of these into our core bundles and use lightweight installers to reduce the impact to your machine.

SqlPackage.exe changes

SqlPackage.exe is a command line tool that gives many of the same features used in SSDT (to publish, extract, import and export databases). If you want to take advantage of the latest features such as Azure Key Vault support for Always Encrypted in SqlPackage, we recommend you install the DacFramework.msi which includes all the Azure DLLs needed to connect and publish to Azure SQL DB.

  • SSDT will continue to install SqlPackage.exe in "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130" so that users running on build agents won't have scripts broken, but this will not have Azure support at present.
  • SSMS now has its own copy of DacFx, so updates to DacFramework.msi will not affect SSMS (and vice versa).
  • DacFramework.msi installs to "C:\Program Files (x86)\Microsoft SQL Server\130\DAC\bin\SqlPackage.exe" and updates independently of SSDT / SSMS.
  • We will work to get an easier installation for future updates so you do not need an MSI to install SqlPackage.exe

Nuget packages for DacFx

Starting this month we're releasing a nuget package containing DacFx DLLs for use in any application. This is initially targeted at supporting Visual Studio vNext (aka "Visual Studio 15") and so the version does not match the current MSI release, but we'll be updating it soon and will release regular updates to match our releases. Nuget packages can be used when building an app that calls into DacFx, but can also be used to get the latest version to a local folder easily. The main DacFx dependencies are bundled in this nuget so you can run it on a machine without any other dependencies. You can get the x64 package here, and the x86 package here.

Going forward we will aim to have more tools available via nuget for easier acquisition & updating in ALM / build agent environments.

Extension developers

For anyone extending SSDT, note that we now use version 13.100 for many. We are adding binding redirects to Visual Studio to ensure that anything you built against older versions will work, but for the latest features you may want to target this version.

Comments

  • Anonymous
    June 30, 2016
    Now we just need a nuget package with the strongly typed model, and the sky is the limit: https://github.com/Microsoft/DACExtensions/issues/1
    • Anonymous
      June 30, 2016
      Great point. I also need to update the strongly typed model and use the new nuget packages as the references in the samples... will try to get this done as I'm behind on updating that!
  • Anonymous
    June 30, 2016
    Great work on this. Good to see isolation at this level as well as an official Nuget package which Ive had to create manually myself up to now.
    • Anonymous
      June 30, 2016
      Thanks Justin!
  • Anonymous
    June 30, 2016
    A couple of questions: 1: Why are the .pdb files included in the NuGet package - is it intentional?2: Why are there x64 and x86 packages - is there unmanaged code involved?3: Assume this means that the 3 or 4 required MSI installs on users PCs are no longer needed (Types, SQLDOM and DacFx) ?
    • Anonymous
      July 05, 2016
      Thanks Eric. That's a good question - this has been the pattern for internal nuget packages and we followed this. We will look at whether the pdb files should be left out and may revise this in a future update to the nuget packages. Appreciate you raising this.Kevin
      • Anonymous
        July 06, 2016
        Why are there x64 and x86 packages – is there unmanaged code involved?
        • Anonymous
          November 08, 2018
          The comment has been removed
  • Anonymous
    June 30, 2016
    Sorry, one more Q:Should the Microsoft.Sqlserver.Dac.dll not have a new "private" Assembly version, to prevent an app from loading a (potentially incompatible) version? (and possible also the other DLL files)
    • Anonymous
      July 05, 2016
      We do not believe this requires an incremented private assembly version. We do not recommend or advise GAC'ing these DLLs. Please let us know if there's a different specific concern here and how it might impact you. Thanks again for the feedback!Kevin
      • Anonymous
        July 06, 2016
        If the same dll is installed in GAC (and updated having the same assembly version) an app will load the version from GAC, not the one from the NuGet package, unless the one from the NuGet package has a NON-GACed assembly version. - but do not know if this could potentially cause any pain...
        • Anonymous
          July 06, 2016
          So in this case, the Dac DLLs are never installed in the GAC by any Microsoft installer, and we'd recommend against doing it yourself. For the Microsoft.SqlServer.TransactSql.ScriptDom.dll we depend on, this has been minor-version bumped to 13.100 (from 13.0) to avoid conflict with the GAC.Thanks,Kevin
  • Anonymous
    July 03, 2016
    Great step forward.Please don't stop here, though. It would be great if all the .NET SQL Server assemblies were available via NuGet. Right now there are a variety of dubiously-maintained and unofficial NuGet packages that bridge this gap.For example: https://www.google.com.au/#q=reportviewer+nuget
  • Anonymous
    July 13, 2016
    So can I just confirm these points:- If I want Always Encrypted support in SqlPackage, I have to install it separately using DacFramework.msi, and use the version found at C:\Program Files (x86)\Microsoft SQL Server\130\DAC\bin\SqlPackage.exe- The version of SqlPackage installed by SSDT will NOT currently support Always Encrypted.Thanks!
    • Anonymous
      July 14, 2016
      If you want to use Azure Key Vault (and do an operation that causes any data motion, such as encrypting a new table) then you need the separate DacFramework.msi install. For all other operations (e.g. encrypting a column using certificate based AlwaysEncrypted) then you can use the SqlPackage or SSDT to publish. We're working on full AKV support with interactive sign in etc. in SSDT but it's not in the current release.