Comparing Automation Add-ins to Visual Studio Packages

From: An Interested VS SDK User (with our comments in brown)

I would like to suggest that it's a pity (of course, it's my personal opinion) that the strategy to separate add-ins and packages still continues in Whidbey. This strategy undoubtedly made sense until 2003 when the VSIP was not free. However, it's a different time now; everyone can write a package extending VS. Still, in many cases add-ins are more convenient for users - for example, users can easily learn how to enable/disable an add-in. In other cases, like implementing a custom project system, writing a package is quite natural way.

So what am I talking about? According to the VSIP docs and, if I understand correctly, to the official policy of Microsoft, add-ins can only use a very restricted set of interfaces which don't allow to do even the very basic things like colorizing text in the code editor and listing changes in a document. If you want something else, please write a package. But as I noted before, it's often much more natural to have an add-in that does e.g. advanced text coloring. So add-in authors should resort to the trick with casting EnvDTE to IServiceProvider that is not officially documented (and obviously not all of them are aware of this trick). It would be nice if in Whidbey there would be an officially supported way for an add-in to get access to VSIP functionality. Developers could then make choice between add-ins and packages based on how the product is supposed to be actually used, not on reasoning like "oops, function Foo.Bar is not available in EnvDTE - let's make a package".

Hi IVSU,

I agree that the line has blurred a bit between add-in's and package's, but I don't think we'll be seeing a drastic change in the extensibility architecture anytime soon. There are a lot of vendors that have invested heavily in both packages and addin's, and there is an expectation that these can be readily ported to future version(s) with only a modest amount of work.

Macros and Addin's are certainly technologies that are easier to grasp, and definitely target the individual VS user. Whereas, the VSIP SDK (now called the Visual Studio SDK), is a much larger beast who's ultimate purpose is to allow for integrating new languages into the IDE. It's these interfaces that the various language teams implement and interact with, to wire their products into the VS environment. The VS SDK essentially exposes the internals of the IDE, allowing for a much tighter integration into the envirionment. As such, it's a lot larger than the DTE automation model, and it does take a bit of work to master. I've been supporting this stuff for over 2 years now, and I'm still not comfortable with some areas of the VS SDK :-)

Bob read this and added: One thing I'd suggest is to consider the opposite approach: Why not make packages easier and leave add-ins to the stuff they're good at?

The policy of add-ins being restricted to using the documented automation interfaces, is by and large a relic from when the VS SDK was not freely available. While it's not widely known, the ability to retrieve various services/interfaces documented in the VS SDK via using IServiceProvider is perfectly legal, and is no longer considered a "hack". Originally, there was some internal debate about advising customers about using this technique, as there were some questions as to whether this functionality would be carried forward. Though that's no longer an issue today. But it does appear we don't have this documented. We blogged the reverse scenario (getting _DTE from a package in one of the first Dr. eX blogs) but never did follow up with how to access VSIP interfaces from an add-in.

Jim: Actually we did write a topic on how to access VSIP interfaces from an add-in. In the Beta 2 release search for the topic called Walkthrough: Calling into the Environment SDK from Automation.

I believe there are plans for a better topic describing when to use macros, automation, addins, and packages. But I haven't actually been able to locate it as of yet. I'll send a bug up to doc team just to make sure that happens. The following page off the Extensibility site though may be a help in the interim: http://msdn.microsoft.com/vstudio/extend/vseoverview/.

It's important to point out that the add-in model was never designed to allow developers to customize or create editors, or implement other advanced features like language services, custom projects, or source code control integration for example. Advanced features such as these, are the pervue of the VS SDK.

Colorization for example, is one such feature that is pretty advanced. Colorization is actually provided by the individual language services, as it's the language service that knows how to parse the source file(s), and identify the various tokens for a given language. This scanning and parsing typically needs to take into account such things as import chasing, and build options as well (to mark undefined code in a #ifdef block of C++ for example). This in turn requires the language services to be very dependent upon the language's project system as well.

In all honesty, I wouldn't advise attempting to modify an existing language service's colorization support, unless said language service actually provided the hooks for you to do so. To date, none of the language services shipping in VS actually do this, nor are they designed as reusable components in and of themselves. The only supported way to go about modifying colorization today, is to implement a new language service, which is obviously not a trivial undertaking.

Given the number of threads we see on this particular topic, it's definitely something that needs to be highlighted in our documentation, and we do have a documention bug on this to ensure it happens.

Developers should make the choice of whether to use an add-in or package based upon the sort of functionality they are looking to implement. It's probably most difficult to choose when simply implementing commands, toolbars and toolwindows, as you can pretty much do this from either a package or an add-in. If you are most comfortable with the add-in model, then it's probably best to go with what you know. If you require tighter integration with the environment or suspect you will eventually be offering your own services, extending the automation model, or implementing some advanced feature, then a package is certainly the wiser choice.

Jim: And unlike add-ins, packages provide some security with a load key access system.