Add-in Pipeline Scenarios
The add-in pipeline object model provides the flexibility for host applications and add-ins to interoperate in the following ways:
Backward compatibility. Newer versions of the hosts or add-ins can operate with their older counterparts.
Isolation. You can move one or more add-ins into an application domain in the host process or in an isolated process.
Sharing. You can use an add-in in multiple communication pipelines.
The following illustration shows a simple communication pipeline and its segments.
Standard communication pipeline
.png "Add-in pipeline model.")
Backward Compatibility
There are two scenarios that demonstrate backward compatibility.
New Host, Old Add-Ins
The following illustration shows how a new host can work with an old add-in.
Communication pipeline with new host and old add-in
.png "Pipeline scenario: new host, old add-ins.")
In this backward compatibility scenario, the new host (Host v2) can work with an old add-in (Add-in v1) because its add-in-side adapter (Add-in-side adapter v1->v2) converts the types into a format that the old add-in can understand.
The new add-in (Add-in v2) has its own view and adapter segments for communicating with the new host.
Old Host, New Add-Ins
The following illustration shows how an old host can work with new add-ins.
Communication pipeline with old host and new add-in
.png "Pipeline scenario: old host, new add-ins.")
In this backward compatibility scenario, the new add-in (Add-in v2) can work with the old host (Host v1) because its add-in-side adapter (Add-in-side adapter v2->v1) converts the types into a format that the old host can understand.
Varying Isolation Levels
You can activate add-ins in a new process or application domain by using the appropriate overloads of the Activate method. This isolation may be necessary for the following reasons:
To handle situations where the host application changes and its new dependencies cannot be accommodated by the older add-ins. For example, this might happen when the host application upgrades to a new version of the .NET Framework.
To achieve reliability by having the add-in run in its own process.
Create a sandbox for the add-in. For example, a host application and an add-in have different levels of trust as specified by the AddInSecurityLevel enumeration.
The following illustration shows a communication pipeline with two add-ins, one of which is in an isolated process. In the illustration, OOP indicates an isolated process.
Communication pipeline with isolated add-in
.png "Pipeline scenario: isolation levels.")
In this scenario, a pipeline developer has two different versions of the contract and adapters: one is optimized for cross-application-domain communication and the other is optimized for cross-process communication. Neither the add-ins nor the host needs to be aware of the differences because they use the same views regardless of the contract and the isolation level.
Shared Add-Ins
You can use an add-in with multiple hosts, provided that the add-in is compatible with the hosts. For example, you can use a shared add-in to implement a toolbar that provides an Internet search for a host Web application. Another example is a shared add-in that provides spam filters and virus protection for e-mail servers or e-mail clients.
To enable the add-in to operate with its new host, you must create a new add-in-side adapter that converts from your add-in view to the host's contract.
The following illustration shows how an add-in (Add-in A) can be shared by two host applications (Host A and Host B).
Communication pipeline with shared add-in
.png "Pipeline scenario: shared add-ins.")