The Art of SQL Server Database Administration, Development, and Career Skills for the Technically Minded
We know that Microsoft doesn’t officially support developing external AddIns for SSMS. We also know that the AddIn framework has been deprecated. Microsoft will continue to support extending Visual Studio through the newer framework VSPackage, but where does that leave SSMS extension development?
What we know for sure. Microsoft currently extends the core SSMS product through this very framework. Proof of this can be found in the default installation folder of SSMS. Look in the Tools\Extensions\Application folder and you will find a large collection of pkgdef files along with a VSIX Manifest file that declares them for inclusion in the core product. Obviously Microsoft develops it’s own extensions to the VS Shell that is SSMS through the VSPackage framework.
C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\Extensions\Application
Open up this manifest and you get clues as to how you would need to modify your own developed VSPackage extension. The first item of note is that SSMS 2014 utilizes a tag declaring IsolatedShell Version 1.0 and product name as SSMS. If you google VSPackage extensions for other Isolated Core products that are based on Visual Studio you will find the content of this tag is always whatever product name you’ve given your Isolated Core based product. So knowing that MS named this ssms is important.
The second item of note is the way pkgdef files are declared in the manifest. As you look through the default manifest that comes with SSMS you find that lots of UIs you probably use every day are built as VS extensions. The Extended Event UI that we talked about in an earlier post for example.
So, it’s stands to reason that using VSPackage to extend SSMS in your future projects – after AddIn is officially dead – is not only possible but currently being used. The downside right now is information and examples of folks actually doing this in the wild is extremely scarce. I’ve really only found one example. The good news however is it does seem to have worked in this one example.
The third thing to note about the manifest above. It is a version 1 VSPackage manifest format. If you develop a VSPackage in VS 2012 or 2013 they both create packages in the version 2 format. What does that tell us? It tells us that SSMS for SQL Server 2014 core extensions such as the Extended Event UI above were developed in Visual Studio 2010. Just an assumption but seems like a logical one.
In the example I linked to – the one that demonstrates successfully extending SSMS with a package originally meant for Visual Studio – the extension is a 2010 package.
In our ongoing example of modifying the SSMS code window based on connection I decided to try and take a stab and my own VSPackage extension. There is an extension written by Nate Greenwood already built for Visual Studio that I really like. Nate provides source code and all. It allows you to add a watermark to the code window. My thought was that I could set up a few watermarks based on whether I’m connected to Production, DevTest, Stage etc in SSMS. For example, production could be guarded by the White Ninja like my Visual Studio environment is.
First problem is this project was written in VS2012 so I had to built it out again for VS2010 to get the version one VSIX packages and manifests. After working with the project for several days straight I had zero luck getting it to work. The package works in Visual Studio but I can’t seem to get it to work in SSMS. The package shows up in the registry – I can even get error message to show up meaning SSMS is trying to load it. My guess is that the adornment layers that this extension utilizes are different or not there in SSMS – but that is just a guess.
At this point – I don’t really have anything to show for my work – but I have learned a lot. I still have hope. I’m confident that given some time, and possibly a high enough bounty on Stack Exchange, I can crack this. If so, I’ll return and update this post.
Looks like there are some deeper issues with VSIX and SSMS versions earlier than the one based on the 2015 visual studio shell. They are documented on Connect here:
It appears however that on SSMS versions using the 2015 (and above ??) shell VSIX should be implementable. I will probably tackle this once I get everything installed with a follow up post.