Did you know? DZone has great portals for Python, Cloud, NoSQL, and HTML5!

Keyvan Nayyeri is a Ph.D. student in Computer Science and previously held a B.Sc. degree in Applied Mathematics. He was born in Kermanshah, Kurdistan, Iran in 1984, and is currently living in San Antonio, TX.

His primary research interests are Programming Languages & Compilers and Software Engineering.  He’s also a software architect and developer with focus on Microsoft development technologies as well as Open Source platforms.

Keyvan is an avid community leader and contributor who has written four books for Wiley/Wrox and several articles for prominent community websites. Also he has contributed to many Open Source projects.

As a result of his long-time contributions to the community, he has received several recognitions and awards from Microsoft, its partners, and community websites.

Keyvan is a continues learner who loves to study, learn, and discover new technologies everyday, and is enthusiast for serving to the humankind through his research and contributions.

For a long time he has been blogging about various topics on his blog that has become a rich resource for software developers. His blog is available at www.nayyeri.net.

Keyvan has posted 36 posts at DZone. View Full User Profile

Visual Studio Add-In vs. Integration Package - Part 3

09.08.2009
Email
Views: 1982
  • submit to reddit

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.

VSPackage structure

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.

 

References
Published at DZone with permission of its author, Keyvan Nayyeri. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)