Russ Thomas – SQL Judo

The Art of SQL Server Database Administration, Development, and Career Skills for the Technically Minded

SSMS Day 30: VSPackage and SSMS

31 Days of SSMS: Table of Contents

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.

9 comments on “SSMS Day 30: VSPackage and SSMS

  1. Evgeny
    July 3, 2015

    Hi Russ,
    How are you doing?
    I also try to make the VSIX package for SSMS

  2. Jan B.
    October 18, 2015

    Hey Russ. I’m sure you will be very suprised if you put your extension folder (which has all dll and pkgdef in there) as a sub folder into the extension folder of management studio. Next you have to go to the registry key called package (located under sql management studio key \ ), add your package guid (make sure you put the open and close curly brackets within), add a dword key called SkipLoading to the key and give it a value of 1. at next start of ssms your vspackage will load.

    • Russ Thomas ( @SQLJudo )
      November 2, 2015

      Interesting, I’ll have to give it a try… thanks.

    • CK
      March 1, 2017

      Thank you for you suggestion! This worked like a charm.

  3. Evgeny Vorobyev
    March 11, 2016

    Hi Russ,
    I also want to use VSIX in my SSMS Addin. But all my attempts failed:(
    Do you have progress?

  4. Rickard
    October 1, 2016

    Hi. After spending most of the day combing through google,
    Check this:

    I made an atempt myself:
    1. Creatiing a VSIXProject in Visual Studio 2015
    2. Adding a CustomCommand name FirstCommand (does nothing/boilerplate)
    3. Creatting a .reg fil (this step is important, se how it’s done via the link)
    4.Run the .reg, SSMS won’t load the addin if you forget this
    5. Put the dll and pkgdef in :
    C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn\ManagementStudio\Extensions\{MyExtention folder}

    And voila! Under the Tools menu in SSMS 2016, “Invoke First Comand” was available.

    This blog got me started, so Im happy to give som info back 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: