Understanding the Add-in Pipeline in Visual Studio Tools for Applications
Visual Studio Tools for Applications is based on the standard add-in programming model that was introduced in the .NET Framework 3.5. Visual Studio Tools for Applications provides a complete implementation of the .NET Framework add-in pipeline. When you integrate Visual Studio Tools for Applications with your application, you use the implementation of the add-in pipeline that is provided by Visual Studio Tools for Applications, rather than implementing your own.
Overview of the .NET Framework Programming Model for Add-Ins
The .NET Framework add-in pipeline is a series of assemblies that that facilitate the exchange of data between a host application and an add-in. The host application uses the pipeline to discover and load an add-in. After an add-in is loaded, the add-in and the host application use the pipeline to call into each other and pass objects between each other. For example, an add-in might call methods in the host application to automate the application. Similarly, the host application might call methods in the add-in to use a service that is provided by the add-in.
The following illustration shows the pipeline.
Add-in pipeline
.png "Add-in pipeline model.")
The host application is at one end of the pipeline and the add-in is at the other end. The pipeline is composed of three main kinds of assemblies:
In the middle is an assembly that defines a set of contracts. A contract is a non-versioning interface that defines the protocol for types to communicate across an isolation boundary, such as an application domain or a process. All contracts derive from the IContract interface.
Next to the host application and the add-in are assemblies that define a set of views. These are abstract classes or interfaces that define the methods that the host application and the add-in use to call into each other. Because the host application and the add-in access only the views, the other components in the pipeline can be changed without updating the host application or the add-in.
In between the contracts and the views are assemblies that define a set of adapters. These are classes that convert the data that is passed through a contract into types that are understood by the views used by the host application and the add-in. If an adapter converts data from a view to a contract, the adapter must implement the contract. If an adapter converts data from a contract to a view, it inherits or implements the view.
For a complete discussion of the pipeline, see Add-in Overview and Pipeline Development in the MSDN Library for Visual Studio 2008. For more information about the pipeline components, see Contracts, Views, and Adapters in the MSDN Library for Visual Studio 2008.
One of the key benefits of the add-in pipeline is that it enables applications to run add-ins in different application domains or processes. This is possible because all calls between the application and add-ins pass through a remotable adapter that implements a contract. This isolation helps to prevent add-ins from accidently or intentionally causing the host application to fail unexpectedly. For more information about isolation boundaries and how remotable objects can be used to communicate across them, see Boundaries: Processes and Application Domains and Remotable and Nonremotable Objects.
Overview of the Add-in Pipeline Implemented by Visual Studio Tools for Applications
The following illustration shows the architecture of the add-in pipeline provided by Visual Studio Tools for Applications.
Visual Studio Tools for Applications pipeline
.png "Add-in pipeline model in VSTA.")
In most cases, you do not directly access the components inside the Visual Studio Tools for Applications box in this illustration, with the exception of the views that are provided by Visual Studio Tools for Applications. For more information, see Understanding the Views in Visual Studio Tools for Applications.
Visual Studio Tools for Applications installs all of its pipeline components in the following directory:
%CommonProgramFiles%\Microsoft Shared\VSTA\Pipeline
This folder is also called the pipeline directory. For more information, see Pipeline Development Requirements in the MSDN Library for Visual Studio 2008.
Pipeline Components Implemented by Visual Studio Tools for Applications
The following table lists the assemblies and namespaces that are included in Visual Studio Tools for Applications that implement each of the components of the .NET Framework add-in pipeline.
Component |
Assembly |
Namespace |
|---|---|---|
Host views of add-ins - and - Add-in views |
Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0.dll Microsoft.VisualStudio.Tools.Applications.Hosting.v9.0.dll |
|
Host-side adapters |
Microsoft.VisualStudio.Tools.Applications.HostAdapter.v9.0.dll |
|
Contracts |
Microsoft.VisualStudio.Tools.Applications.Contract.v9.0.dll |
|
Add-in-side adapters |
Microsoft.VisualStudio.Tools.Applications.AddInAdapter.v9.0.dll |
Additional Components in Visual Studio Tools for Applications
In addition to implementing the .NET Framework add-in pipeline, Visual Studio Tools for Applications introduces several new components. The following table describes these components.
Component |
Description |
|---|---|
Remote type management |
This component provides an infrastructure for associating types in the host application with the proxy types that are used by add-ins. This infrastructure enables the host application and its add-ins to share types and objects across process or application domain boundaries. Most of this work is handled internally by Visual Studio Tools for Applications, but there are two services that you must implement to connect this infrastructure to your host application: the host item provider and the type map provider. For more information, see Exposing Host Objects to Add-Ins and Mapping Host Types to Proxy Types. The remote type management component is implemented in the Microsoft.VisualStudio.Tools.Applications.Adapter.v9.0.dll assembly, in the Microsoft.VisualStudio.Tools.Applications namespace. |
Add-in proxies |
When you integrate Visual Studio Tools for Applications, you must generate proxies for each type in the object model of the host application that you want to expose to add-in developers. A proxy is a type that represents the add-in's view of a type in the host application object model. Rather than using host types directly, add-in developers instead use proxy types. For more information, see Creating Proxies. |
Understanding the Views in Visual Studio Tools for Applications
Visual Studio Tools for Applications provides its own set of views that are implemented by add-ins, and used by the host application. The views are the IEntryPoint interface and several interfaces that derive from it. When you integrate Visual Studio Tools for Applications, you typically use one of these views to load and initialize add-ins. For more information about how the views are used during the loading process, see Understanding the Add-in Pipeline in Visual Studio Tools for Applications.
The following table lists the views that are provided by Visual Studio Tools for Applications.
View |
Description |
|---|---|
Defines methods that the host application can call to initialize the add-in, and to clean up resources that are used by the add-in. |
|
Defines a method that the host application can call to get an instance of the entry point in the add-in. When you specify an entry point by using ProxyGen.exe, the entry point implements the IExtendedEntryPoint interface. For more information about entry points, see Defining Entry Points and Other Proxy Changes. |
|
Defines a method that the host application can call to initialize multiple entry points in an add-in. |
|
Defines a method that the host application can call to get instances of each entry point in an add-in that has multiple entry points. |
See Also
Concepts
Discovering and Loading Add-Ins
Considerations for Loading Add-Ins
Contracts, Views, and Adapters