Brief Introduction to our Architecture for Managed Add-Ins [Jesse Kaplan]

One of the key benefits of our new managed add-in model is the architecture our system uses to connect the host to the add-in. Our system defines something we call the Add-In Communication Pipeline that defines a series of abstractions that allow hosts and add-ins to version independently and be completely unaware of how the other side is built or how information is passed across isolation boundaries. Starting next week we’ll be starting a series of articles that talk about how to implement this pipeline and the details on why we have certain restrictions and recommendations. For a complete introduction please read our article in the March 07 issue of MSDN Magazine. In this post however, I’d like to give you a quick reference with a brief introduction to our architecture and a high level view of some of the scenarios it enables.

Pipeline Architecture

The most interesting thing to note about the above diagram is the direction of the static dependencies. The host and add-in only ever depend on one component (the view) which itself has no dependencies elsewhere on the system. This means that the host and add-in are completely unaware of each other and the contracts that are used to cross the boundary.

Pipeline Components

Views: The host and add-in views are assemblies that contain nothing but a series of abstract classes that represent the host and add-ins view of each other. These view assemblies take no dependencies on other components in the system. This is what you would traditionally think of as the object model and the public surface area a host would expose to its add-ins (or vice-versa).

Contract: The contract assembly contains the non-versioning types (contracts) that are loaded in both sides of the isolation boundary and define the communication protocol over that boundary. These assemblies also take no dependencies on other components. Neither the host nor the add-in ever program directly against the contract and thus they often sacrifice a nice programmable surface area in favor of a more efficient/stable protocol.

Adapters: The adapter’s role is to convert to and from the views and the contracts. It is in these adapters that you would put any code to adapt between different versions of views and contracts.

Enabling Host Backwards Compatibility

One of the most common needs from hosts providing an extensibility model is the ability to keep add-ins built against older versions of the host working on the new one. Our model makes it much easier as the host doesn’t have to worry about multiple add-in versions inside the application itself: instead it writes an adapter between the old view and the new contract (see above) and places any fix-ups in that adapter. When you wish to stop supporting an old version you simply stop shipping an adapter for it.

Next Time

Next time we’ll go into some depth on what constitutes a contract and soon after get into the details on how to implement the adapters.