You are here:   Blog
Register   |  Login

Blog Archive:

* Can be used in order to search for older blogs Entries

Search in blogs

Blog Categories:

* Can be used in order to search for blogs Entries by Categories

Blog Tags:

* Can be used in order to search for blogs by keywords


Awared MVP


Microsoft® Community Contributor 

Microsoft® Community Contributor

 Read this before you use the blog! Maximize

Recent Entries


Written by: ronen ariely
10/05/2017 21:51 RssIcon

Good day guys :-)

I want to bring a short story regarding a bug report related to SSMS 2017 and a User defined Extensions. I spend several hours to find the issue and I hope this blog will help you save the time. Therefore, if you are developing extensions (addins) to SSMS using VSIX template, or if you interesting in the subject, or if you simply tried to install extension and the installer did not recognize the SSMS, which installed in your machine, then this blog is for you.

Episode 1: The issue

Several days ago, Microsoft released SQL Server Management Studio version 2017! 

Wow… great we all need to download it and install it! 

Unfortunately, I started to get reports that my SSMS's extensions does not work well on the new version :-(

Checking the issue, I tried to install the extension myself, and I found out that there issue relate to the installing process.

When we double click a file in windows OS the operating system find the appropriate application which should execute/open this file. Same with the installation file (.vsix) created with Visual Studio. In the case of (.vsix) file we have an installer execution file named sixinstaller.exe, which came with the SSMS/Visual Studio installation, and should execute .VSIX files.

In the first step of the installation process the installer check which version of Visual Studio and SSMS we have in our machine, according to the configuration of "install Target" parameters in our project's manifest (at "source.extension.vsixmanifest" file).

* The image above show example of "install targets" which includes SSMS 2016, SSMS 2017, VS 2015, and VS 2017

The issue was that the installer did not find any installation of SSMS 14.0.17 and above (last release May 2017), but it worked fine on any machine which includes any version before 14.0.17, for example version 14.0.16150.0 from one month back could be found without any issue. This seems to be like a BUG in the last version of SSMS.

Since the installer could not find the installed application, it could not move to next step – represent us a list of installed versions and asking us on which version do we want to install the extension.

The above image show a "normal state", where the installer found that we have 2 versions of SSMS (2016, and 2017 version before 14.0.17), in addition to VS version 2015.

I tested the installation on more than 15 different machine, and the result were consistent!

1. At any machine that includes the SSMS released on May (any version from 14.0.17 and above), the installer did not find the SSMS.

2. At any machine which includes older version of the SSMS (for example version 14.0.16150.0) the installer found the installed SSMS.

The results drove me nuts. It was clear to me that the VSIX project cannot be installed on the new version, since the installer does not recognize the new SSMS.

Anyhow, at this time, I contact several people I know from the SSMS developing team. Great guys help me in the past! After all, who can solve the issue better then these who developed the application, and if this is a bug they should know about it :-)

* It's great time to say thanks (again) to Ken(@sqltoolsguy) , Matteo (@matteo_taveggia), and all Microsoft developing team for contact me back, and for helping in general (I am not sure if all want me to put their name in public so I will let them be anonymous at this time).

Episode 2: Finding the solution

In the meantime, while I was waiting for one of the SSMS team members to contact me back, I keep search for solution and I came across this post, where I notice this:

QuoteIf you have trouble installing the SSMS extension, try the following command line:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\vsixinstaller.exe" "full path to extension.vsix"

I am familiar with the option to use the installer "vsixinstaller.exe" directly, and I even use it in order to uninstall my extension dynamically (I have uninstall button which based on this app).

Well, I thought to myself… what do I have to lose... I tested the option to install the extension using the command shell, and it worked :-)

* Strange point: using the command shell the installer found the SSMS well, but now it did not find the VS 2017... VERY WEIRD BEHAVIOUR... so I continued to investigate the issue

Episode 3: exploring and understanding the issue

OK, I have the solution but I have the needs to understand, so the issue was not close yet.

Let me jump to the end:

I found out that all the machines, which had the new version of SSMS, coincidentally also includes VS 2017 installed, while all the machines which include the older version of the SSMS includes VS 2015.

The issue is that by double click the VSIX file the operating system executed the last version of the installer.

If I execute the installer on machines with VS 2017, then it executes the installer from the VS 2017 folder, and that one does not find the SSMS which use VS IDE 14 like the VS 2015. But if I double click the installer on machines without the VS 2017, then it executed the installer in the VS 2014 folder, which is the same as the SSMS 2017, therefore it worked fine

This is why using the command line (command shell) and execute the correct installer from the "Microsoft Visual Studio 14.0" folder worked fine.

The issue is solved!


If someone has VS 2017 installed in addition to the SSMS, then he should use the command line in order to use the correct installer, and he should not double click the VSIX file.

I hope this information will help others in the future... before you spend several hours to explore the issue

In the word of Matteo: Oh yeah - *always* use the “right” version of vsixinstaller.exe!

Have fun,

signature  Ronen Ariely
 [Personal Site]    [Blog]    [Facebook]   [Linkedin]