The Art of SQL Server Database Administration, Development, and Career Skills for the Technically Minded
Yesterday we talked about setting up your Visual Studio environment to build an SSMS Add-In. Today we’ll talk about deploying the Add-In. At first glance this may seem like we’re skipping a step. Don’t we need to develop and debug something before we deploy it? We’ll hit that more tomorrow. Read on for why I deploy now. ( that sounds like click bait doesn’t it ).
I like to deploy my Add-In shell early so that throughout each step of developing my Add-In I can continually debug, research, and test minor changes, one by one. Remember, what we are doing is not supported nor well documented so we have to work slowly through each step. That may sound like testing in production but I do this in an isolated virtual environment with an install of SSMS that I don’t mind blowing away and reinstalling if I have to. It’s a poor mans experimental environment. Microsoft offers this when developing VS extensions – with SSMS you have to build your own manually.
With your environmental environment ready, take the project we started yesterday and go ahead and build the project in release mode. (Building in debug mode doesn’t really offer any help when working with SSMS like it does for VS)
Once you’ve done that you will find the package in the bin\release sub folder of the project.
Open up the file with AddIn extension in your favorite text editor and modify the following elements.
– 1: Change the <HostApplication> node to Microsoft SQL Server Management Studio
– 2: Set the Version to * and point the <Assembly> element under the <AddIn> node to the bin folder you are developing in. This will allow your experimental install of SSMS to continually be updated each time you compile a change.
With this done you’ll now need to copy the AddIn file to a location where SSMS can reference it for including your AddIn on startup. You have options for deploying for single user, all users, etc etc. For simplicity’s sake let’s just deploy for everyone. You do that by copying the AddIn file to C:\ProgramData\Microsoft\MSEnvShared\Addins.
If you’re like me and are lucky enough to have some Red Gate tools you’ll likely notice their AddIn files in this same location. It’s worth a look to take a peak inside and see how the “Pros” do it.
That’s pretty much it. Deploying an AddIn is really quite simple. Since the project we built doesn’t do anything other than create an entry on the Tools menu right now, verifying that everything worked is as easy as opening up SSMS and seeing if you now have a new menu item under Tools. BaZinga!
With a project shell ready for development and an experimental install of SSMS to develop and debug against you’re all set. Tomorrow we’ll actually make that tool do something and take a deep dive into exploring all the assemblies, and interfaces available to you.
There isn’t much difference between this deployment and what you’d do when you have a complete extension ready for primetime. But we’ll save that discussion for the last post where we look as VSPackage and installers for making deployment elegant.