Keyvan Nayyeri

Two days ago I started a new post series to discuss Visual Studio add-in and integration package in order to introduce their structure, applications, differences, commonalities, and how to upgrade from an add-in to a VSPackage. My main goal is to cover some aspects of this discussion that have been an ambiguous part of Visual Studio Extensibility for a newbie.

In the first post of this series, I gave a quick overview of the past history of Visual Studio Extensibility, these two options, and how they evolved during the past decade or so. In this second part I want to review the technical structure of an add-in along with its applications.

What is an Add-in?

In fact, the term add-in refers to something general in Microsoft products including Visual Studio IDE and Office Suite and in Visual Studio it’s known as VSAdd-in. But it’s common among Visual Studio users and developers to simply call it “Add-in”.

But what’s the application of an add-in and why it’s designed as a part of Visual Studio extensibility?

Add-in is actually an extension to Visual Studio that lets developers apply high level APIs of the Visual Studio and Development Tools Extensibility (DTE) to extend Visual Studio in several ways but with some limitations that relate to the API that they can use.

Above paragraph states some important facts about add-ins:

• Add-in is an extensibility option.
• Add-in uses high level APIs. This is important when we talk about VSPackage that uses low level APIs.
• The main APIs to use with add-ins are those that are part of the Development Tools Extensibility (also known as DTE). You’ll read a short overview of the DTE later in this series.
• There are some limitations to build add-ins and use them. Add-ins use some high level APIs and this restricts them in some points. You’ll read more about these limitations later in this series.

Now that you read a quick definition of add-in and a short description about important aspects of an add-in, let’s dig into more details about add-ins.

Technical Structure of an Add-in

From a technical point of view add-in is a compiled package of code that can run by a mechanism in Visual Studio known as Visual Studio add-in system. This is in opposite direction to the definition of VSMacro that is not a compiled piece of code.

Add-in is a COM component. It means that add-in, like many other COM components, implements a programming interface for a component. In general Visual Studio Extensibility consists of lots of these interfaces and their corresponding implementations to enable interoperability between .NET and COM.

The development mechanism of add-ins is a built-in part of Visual Studio and there is a Visual Studio template for this purpose.

From a technical point of view add-in implements IDTExtensibility2 interface from EnvDTE80 namespace (this is of course what you see in Visual Studio 2005 and 2008 and names are different for prior versions). This interface contains five methods that can be implemented to handle events that let you implement your logic for these main events including OnConnection, OnDisconnection, OnAddInsUpdate, OnStartupComplete and OnBeginShutdown. The structure of an add-in is shown below.

Beside this, there is an XML file with a .vsaddin extension that acts like a configuration file for your add-in and you must configure it.

Before Visual Studio 2005, the deployment of add-ins was a little hard and required the registration of COM assemblies on the machine but thank to the introduction of this .vsaddin file, now you just deploy the assembly and this configuration file to a specific path.

You’re able to integrate an add-in into Visual Studio as a part of some user interface elements. You can add a Visual Studio command for your add-in to the IDE and then use this command to achieve many things.

For example, you can add your add-in to the user interface as a new menu item for default Visual Studio menus or right-click menu.

Since add-ins have access to the automation model API, they can do many things that I outline some of them here:

• Trigger your logic for various events
• Manipulate some default Visual Studio windows like Tasks List, Output or Error List
• Manipulate the text in documents regardless of being code or not
• Manipulate the code in code files using the code model
• Manipulate solutions, projects and project items
• Manipulate and customize the build process
• Work with source control and implement your own source controls or customize existing ones

These are some main tasks that add-ins can do but besides them, you’re able to design your own user interface for the add-in to show to the user in order to return outputs or get inputs. Moreover, you’re able to integrate a Tools Options Page in order to have dynamic configuration and settings for your add-ins.

There is a Visual Studio mechanism to load and run add-ins. This mechanism looks for add-in files in specific paths (that you can modify) and then loads all valid add-ins (that implement the interface and have a valid .vsaddin file). After loading these add-ins, it calls the specific method whenever that event type occurs. You saw that there are five main events that an add-in implements and can respond to them when Visual Studio calls such methods.

By implementing an extra interface called IDTCommandTarget and registering a command for your add-in, you’re also able to respond to the command whenever it’s called and this lets you do much more things than what you can do by default implementation of add-in. This also lets others to develop macros and add-ins that will apply your add-in.

In general, there are many goals that can be achieved with add-ins quickly and easily. The development and deployment process of add-ins has been made much easier in Visual Studio 2005 and 2008, and now it’s the fastest way to extend Visual Studio with high level APIs.