I had another person tell me today that they decided to scrap the Add-in code they wrote and start writing VSIP packages. My response to them is always “Why?” Not too many people know that you can go from the automation object model into VSIP, and from VSIP to the automation object model, with just a little bit of code. And that little bit of code can save you a lot of work, letting you keep your existing code base and migrating it forward to use something that may not be supported in one programmability model or the other.

 

When an Add-in, wizard, or macro is loaded/run, an instance of the DTE object is made available to that code. It is not well known (we actually tried to hide this information in the pre-free VSIP days) that DTE is a service provider, meaning you can get to any service on the VSIP side simply by doing a QI on the DTE object for the interface IServiceProvider, and then calling IServiceProvider::QueryService(…) to get to the desired service.

 

Since DTE is a service provider, that means you can get to any automation object model interface from your package. With the IServiceProvider provided to your package when it is loaded, you can call QueryService(SID_SDTE, IID_DTE, …) to get to a DTE object, then you can spelunk the object model to get where you want.

 

This means you can choose whether you want a package or and an Add-in for your code, and can use the other model for the path of least resistance to get the job done. Suppose you have a package and need to put one or two items in the task list. Skip the thousands of lines of code to create a task provider and talk directly to the TaskList object. Or use IVsUIShell from an Add-in to post a command with PostExecCommand rather than using the SendMessage-like ExecuteCommand.

 

Of course, you cannot do everything with an Add-in. For example, you cannot create projects or text document windows, and there are a few other things you cannot do, but you can mix and match the two programming models to fit your needs.

 

One warning: there is a specific license agreement that you must agree to (I have never read it, so I cannot give any more details) if you use VSIP, while the automation object model has no license restrictions regarding creating and freely distributing an Add-in, wizard, or macro. So make sure you understand the VSIP license before starting to use the VSIP interfaces.