Partager via

Crossing the VSIP bridge

  • Article

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.

"urn:schemas-microsoft-com:office:office" />

 

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.

Comments