Creating a Visual Studio Tool Window - VsAddin or VsPackage

Question

Hey Folks.

Simple question - I found two ways to add a tool window to Visual Studio (2008): create an addin or create a package.

(Addin: http://www.codeproject.com/KB/dotnet/vstoolwindow.aspx)
(Package: http://msdn.microsoft.com/en-us/library/bb165051.aspx)

What's the "right" way?

Answer 1

If you are just creating a simple tool window then I suggest going the Add-in route.

Both Packages and Add-Ins are ways of extending Visual Studio. Generally speaking they have the same functionality. Packages are a bit more powerful and allow deeper integration into Visual Studio. But that deeper integration comes with a cost including bigger ramp up times and installation procedures.

Add-ins are designed to be a more light weight extension mechanism. Smaller ramp up time and easier installation.

If all you are doing is tool window with basic interaction of the editor our code model then add-in is the best route.

Answer 2

You can do either, and I've done both. In some ways, addins are a bit easier, but they suffer from some annoying drawbacks.

Add-in:

• +No requirement to install the Visual Studio SDK
• +No requirement to use a Package Load Key (PLK) or sign your distributed binaries
• +Easier development process when you use the Extensibility API (simplified code in many ways)
• +Easier installation process (no wacky registry stuff)
• -Doesn't seem to behave as well as VSPackage-based tool panes
• -I've run into performance issues which prompted me to use the VS SDK COM interfaces instead of the Extensibility ones, leading to a significant performance bump. In other words, my "add-in" is now based on the VS SDK and is only really an add-in because it loads via an XML file instead of the registry. (Also, from everything I can tell, the Extensibility interfaces are just a large utility wrapper around the SDK.)

VSPackages:

• +You can harness the full power of the VS SDK, both its feature set and (potentially, when carefully used) performance advantage
• +Seems to behave more reliably than add-ins
• -Requires signed binaries, a PLK, and a complicated installation procedure
• -Steep learning curve, and many seemingly simple actions are nasty/convoluted. I now have an assembly providing extension methods to perform "obvious (to me)" actions on the COM interfaces. Between that and experience things have improved over time. There are similar options available to the community, which you should seriously consider if you go this route.