I've spent the last day or so playing with an idea for a SSMS add-in. It's something I've been thinking about for a while now but will save the details for another post. What I want to document are my experiences so far as well as how convoluted and poorly-resourced the process of producing an add-in to SSMS is. Here are some of the things you should know about before strating on the journey. Hopefully some of this will save you some pain.
General Points:
SSMS Integration:
Menu Generation:
Resources:
General Points:
- As far as I can tell, Microsoft don't really want you to integrate into SSMS - at least they've no interest in supporting the endeavour.
- Luckily, due SSMS's similarity to Visual Studio, you can broadly follow the same instructions offered up for extending Visual Studio with add-ins, something MS seem to actively encourage.
- There appear to be two ways of skinning this cat: Add-ins and VSExtensions. Add-ins, the route I've taken, are the older of the techniques but are where the majority of the resources are.
- In order to load add-ins SSMS looks in folder locations specified here: HKEY_CURRENT_USER\Software\Microsoft\SQL Server Management Studio\11.0_Config\AutomationOptions\LookInFolders for XML files giving details of the add-ins.
- You can configure things to happen only the first time the add-in is loaded by SSMS or every time the add-in is loaded: ext_ConnectMode.ext_cm_UISetup & ext_ConnectMode.ext_cm_Startup. I've still haven't quite grasped fully how they work.
Menu Generation:
- A CommandBar can contain a CommandBarPopup which needs to contain a CommandBar which is where you place CommandBarButton objects produced by Command objects.
- A Command can exist entirely independently of anything else. They don't have to be attached to CommandBarButton objects.
- A Command hangs around. It doesn't disappear after you close SSMS. To have it do so you need to remove it in the OnDisconnection of the IDTExtensibility2 interface.
Resources:
No comments:
Post a Comment