The very beginning of our journey with SQL Server is the installation process. In previous versions of SQL Server, the data management and development tools were delivered together with the SQL Server installation image. As such, if a developer wanted to install SSMS, the setup of SQL Server had to be used to facilitate the installation.
As of SQL Server 2016, Microsoft made the very smart decision to separate the management tools from the server installation. This is not only a separation of the installation medium, but also a separation of the release process. This separation means that both products can be developed and released without having to wait for the other team to be ready. Let's take a look at how this change affects us at installation time.
In the following screenshot, given as follows, we see the SQL Server Installation Center screen. This is the first screen we will encounter when running the SQL Server setup.exe shown in the installation screenshot. After choosing the Installation menu point on the left, we are confronted with the generic installation options of SQL Server, which have only minimally changed in the last releases. The second and third options presented on this screen are Install SQL Server Management Tools and Install SQL Server Data Tools. If we read the descriptions of these options, we note that both links will redirect us to the Downloads page for either SSMS or SSDT. This is the first clear indication that the delivery of these tools has now been decoupled from the server installation:
After clicking Install SQL Server Management Studio, you should be redirected to the Downloads page, which should look like the following screenshot:
The Downloads page offers us the latest production version of SSMS on the main page, together with any upgrade packages for previous versions of the software. We are also able to see details on the current release and view, download previous releases, and find information on change logs and release notes on the left of the web page:
After downloading the desired version of SSMS, we can run the installation just the same way as with previous versions of the tool. The next immediately noticeable difference to previous versions is the installation program itself. SSMS 2016.x and higher is based on Visual Studio 2015 Isolated Shell, and as such uses similar color schemes and iconography to Visual Studio 2015.
Once the installation has completed, we can start SSMS and are greeted with a familiar starting screen as in all previous versions of SSMS. The subtle differences in the application is exactly that, subtle. The splash-screen at application start shows that the SSMS is now powered by Visual Studio; otherwise there are no major indications that we are working with a tool based on Visual Studio. The interface may feel familiar, but the menus and options available are solely concentrated on working with SQL Server.
Previously, SQL Server and the SQL Server Tools were packaged together. This led to bug fixes and featured additions to the tools having to be bundled with Cumulative Updates (CU) and Service Packs (SP), or general version releases of the SQL Server product. Through the decoupling of the applications SSMS and SSDT from SQL Server, we no longer have to wait for CUs and SPs, or version releases of SQL Server, before we can receive the required/requested features and fixes for SSMS and SSDT. The SQL Server Tools team has taken immediate advantage of this and has made regular releases for both SSMS and SSDT since the general release of SQL Server 2016. The initial release of SSMS 2016.x was in June 2016 and there have been subsequent update releases in July 2016, August 2016, September 2016, and December 2016. The change to version 17.x followed in 2017 and the releases were less rapid, as the port from SQL Server releases and integration into the Visual Studio 2015 shell matured and the preparations for the release of SQL Server 2017 were ramping up. Each release has included a range of bug fixes and featured additions which are much more rapidly deployable when compared to the previous versions of SQL Server and SSMS.
A further advantage of the separation of the data tools from the server product is the reduced overhead of managing the installation and updating the tools in a network. The process of updating an already installed SSMS installation is demonstrated in the following screenshot, where we see that a Check for Updates option has been included in the Tools menu of SSMS:
Further to this, the separation of the tools as a standalone installer will reduce the administrative overhead in larger organizations where software is deployed using centralized management software. Where previously the larger ISO image of an SQL Server installation was required, now a smaller standalone installer is available for distribution.
We also have the option to request that SSMS automatically checks for updates at application start. This will create a notification balloon message in Windows if a new version is available. A sample notification on a Windows 10 machine can be seen in the following screenshot:
Once the update check has been opened, SSMS connects to the update systems of Microsoft and performs checks against the currently installed version and the latest downloadable release of the software. If updates have been found, these will be offered using the update mechanism, as shown in the following screenshot. We are also able to decide if the automated update check should be performed or not:
These enhancements to the installation and update process are not mind-blowing, especially considering that these features have been available in other products for years or even decades. However, these are the first main improvements that have to do with the switch from a standalone application to an application based on the extremely successful Visual Studio Framework.