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.