Udostępnij za pośrednictwem


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

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

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

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

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

Pipeline scenario: shared add-ins.

See Also

Concepts

Pipeline Development