Keyvan Nayyeri

In the first two parts of my new post series about Visual Studio add-in and integration package as two primary options to extend Visual Studio IDE I gave a quick overview of the past history of Visual Studio Extensibility with an emphasis on these two options, and talked about the technical structure of an add-in along with its applications.

Now in the third part I want to go over the technical structure of a Visual Studio integration package also known as VSPackage and talk about its applications to contrast it with add-in structure and applications.

What is a VSPackage?

The second extensibility option that is a part of our discussion is VSPackage.

First of all, let’s make it clear about the name. VSPackage stands for Visual Studio Package and some other guys call it VS SDK Package and it’s also known as Visual Studio Shell Integrated package in Visual Studio 2008 (after the birth of Visual Studio Shell technology). I usually refer to it as VSPackage which seems to be the well-known term.

A VSPackage, as its name suggests, is a component that integrates into Visual Studio environment like a built-in part of the IDE and here is the key point. It integrates with the IDE very well and can do things that add-ins can’t do and this is the primary advantage for it in comparison with add-ins.

VSPackage applies low level APIs of the IDE to accomplish things. These APIs are similar to those that development teams at Microsoft use to build many built-in parts of the IDE.

When you use a VSPackage, you’re actually using a built-in part of Visual Studio and when you develop a VSPackage, you’re developing something like what a Microsoft developer may develop inside the company.

A VSPackage consists of groups of some main elements including:

• User interface elements
• Projects
• Services
• Designers
• Editors

You can develop each of these elements for your VSPackage to integrate a new feature or some new features with existing Visual Studio features.

One of the good examples of a VSPackage is an implementation done by Microsoft as Team Explorer. Team Explorer, a client to work with Team Foundation Server source control, is a VSPackage that integrates some features with Visual Studio.

VSPackage, like add-in, is one of the first level Visual Studio extensibility options that is already known as the most professional way to extend this IDE with a deep integration.

Technical Structure of a VSPackage

Like add-ins, VSPackages are also some components that are compiled in a way to be accessed by Visual Studio COM components that implement interfaces. A VSPackage mainly implements IVsPackage interface but since VS 2005, Managed Package Framework (MPF) is introduced to make things easier and now you just need to derive from a base class named Package that automatically derives from several interfaces including IVsPackage.

Although this is the main part of the package implementation but there are lots of things besides it that make a VSPackage include commands, designers, editors, tool windows, and related stuff that are beyond the scope of this context.

When you want to develop a VSPackage, you need to implement various parts of this component mainly the part that derives from VSPackage. As you can guess, the development of a VSPakcage takes more effort and requires a deeper knowledge in Visual Studio Extensibility and COM programming.

Note that the most suitable language to use in order to develop a VSPackage is VC++. Although other .NET languages such as C# can be used, in some circumstances you face with limitations with these languages.