Add-ins and Extensibility

Add-ins provide extended features or services for a host application. The .NET Framework provides a programming model that developers can use to develop add-ins and activate them in their host application. The model achieves this by constructing a communication pipeline between the host and the add-in. The model is implemented by using the types in the System.AddIn, System.AddIn.Hosting, System.AddIn.Pipeline, and System.AddIn.Contract namespaces.

This overview contains the following sections:

• Add-in Model

• Distinguishing Between Add-ins and Hosts

• Related Topics

• Reference

Add-in Model

The add-in model consists of a series of segments that make up the add-in pipeline (also known as the communication pipeline), that is responsible for all communication between the add-in and the host. The pipeline is a symmetrical communication model of segments that exchange data between an add-in and its host. Developing these segments between the host and the add-in provides the required layers of abstraction that support versioning and isolation of the add-in.

The following illustration shows the pipeline.

Add-in pipeline

The assemblies for these segments are not required to be in the same application domain. You can load an add-in into its own new application domain, into an existing application domain, or even into the host's application domain. You can load multiple add-ins into the same application domain, which enables the add-ins to share resources and security contexts.

The add-in model supports, and recommends, an optional boundary between the host and the add-in, which is called the isolation boundary (also known as a remoting boundary). This boundary can be an application domain or process boundary.

The contract segment in the middle of the pipeline is loaded into both the host's application domain and the add-in's application domain. The contract defines the virtual methods that the host and the add-in use to exchange types with each other.

To pass through the isolation boundary, types must be either contracts or serializable types. Types that are not contracts or serializable types must be converted to contracts by the adapter segments in the pipeline.

The view segments of the pipeline are abstract base classes or interfaces that provide the host and the add-in with a view of the methods that they share, as defined by the contract.

For more information about developing pipeline segments, see Pipeline Development.

The sections that follow describe the features of the add-in model.

Independent Versioning

The add-in model allows hosts and add-ins to version independently. As a result, the add-in model enables the following scenarios:

• Creating an adapter that enables a host to use an add-in built for a previous version of the host.

• Creating an adapter that enables a host to use an add-in built for a later version of the host.

• Creating an adapter that enables a host to use add-ins built for a different host.

Discovery and Activation

You can activate an add-in by using a token from a collection that represents the add-ins found from an information store. Add-ins are found by searching for the type that defines the host's view of the add-in. You can also find a specific add-in by the type that defines the add-in. The information store consists of two cache files: the pipeline store and the add-in store.

For information about updating and rebuilding the information store, see Add-in Discovery. For information about activating add-ins, see Add-in Activation and How to: Activate Add-ins with Different Isolation and Security Levels.

Isolation Levels and External Processes

The add-in model supports several levels of isolation between an add-in and its host or between add-ins. Starting from the least isolated, these levels are as follows:

• The add-in runs in the same application domain as the host. This is not recommended because you lose the isolation and unloading capabilities that you get when you use different application domains.

• Multiple add-ins are loaded into the same application domain that is different from the application domain used by the host.

• Each add-in is loaded exclusively into its own application domain. This is the most common level of isolation.

• Multiple add-ins are loaded into the same application domain in an external process.

• Each add-in is loaded exclusively into its own application domain in an external process. This is the most isolated scenario.

For more information about using external processes, see How to: Activate Add-ins with Different Isolation and Security Levels.

Lifetime Management

Because the add-in model spans application domain and process boundaries, garbage collection by itself is not sufficient to release and reclaim objects. The add-in model provides a lifetime management mechanism that uses tokens and reference counting, and usually does not require additional programming. For more information, see Lifetime Management.

Back to top

Distinguishing Between Add-ins and Hosts

The difference between an add-in and a host is merely that the host is the one that activates the add-in. The host can be the larger of the two, such as a word processing application and its spell checkers; or the host can be the smaller of the two, such as an instant messaging client that embeds a media player. The add-in model supports add-ins in both client and server scenarios. Examples of server add-ins include add-ins that provide mail servers with virus scanning, spam filters, and IP protection. Client add-in examples include reference add-ins for word processors, specialized features for graphics programs and games, and virus scanning for local e-mail clients.

Back to top

Related Topics

Back to top

Reference

System.AddIn

System.AddIn.Contract

System.AddIn.Hosting

System.AddIn.Pipeline

Back to top