CLR Inside Out: .Net Extensibility

(5/16/08, updated MSDN links )

The March MSDN issue is now available on-line.  In this issue you will find our second of two MSDN articles introducing the new System.Addin* Base Class Libraries (BCL).

In our first article we walked through the typical process customers undertake in offering extensibility through their Host applications.  We discussed the functionality that is necessary in offering a comprehensive AddIn solution (i.e., Discovery, Activation, Isolation, Lifetime, Security, Unloadability, and Versioning).  We also walked through some sample Host code and the new System AddIn API’s utilized by the Host.  In addition, we showed some sample AddIn code that clearly demonstrated how the AddIn developer is blissfully ignorant of the underlying mechanics in consuming the object model provided by the Host. 

In our first article we postponed discussing the System Addin pipeline and we promised to show the utilization of the model to enable compatibility as your Host and Add-In version independently. In this article we’ll first go into detail about the architecture of the model. Then we’ll look at version 2.0 of the application we reviewed last month, using it to get an in-depth view of how our pipeline works, and finally using it to demonstrate how you can use our system to keep add-ins working even as the host changes.

Comments (11)
  1. David Levine says:

    Hi Jack (and Jesse),

    Read the MSDN article and had a question about versioning abd backwards compatibility. The example (figure 6 in the article) discusses one level of backwards compatibilty, from version 1 to version 2. Let’s assume more time (and versions) pass, and now it’s up to version 5.

    Would this use an add-in side adapter for each version change so that it formed a versioning pipeline? This would imply that for version 5 to be backwardly compatible with version 1 there would be 4 add-side adapters, V5->V4, V4->V3, V3->V2, V2->V1. In this approach, 4 adapters would handle all the conversions necessary for any add-in built before version 5, (the add-ins would cascade), but the number of interaction points increases as the version difference increases, increasing the complexity of an operation.

    Or would you advocate an add-in for each version change, e.g. V2->V1; V3->V2 & V3->V1; V4->V3 & V4->V2 & V4->V1; V5->V4 & V5->V3 & V5->V2 & V5->V1. This approach obviously requires more adapaters, one per combination supported, but there’s a single interface point between adapaters, and fewer layers of code for a given operation. One advantage is that if a special conversion needs to be performed for a specific version-to-version change it will be easier to implement in this approach.

    Which approach does the current framework “prefer”? How do correct versioning adapters get loaded by the framework? Is there any context information available to the versioning adapters in the middle of a pipeline to help it make decisions based on the end-to-end versioning change?


  2. Hi David,

    The answer is that it depends.  You don’t need new adapters for every version. However, if your component (Host or Add-In), the Addin in this case, provides additional or changed behavior in its public interface then new Hosts require adaptation (a new Adapter).

    It also depends on whether you intend to provide backward compatability version over version.  That is to say, the service provider may break compatability and thus not ship a backward compat adapter.  Of course, your customers may expect at least default bahavior or a not implemented handler, …

    As far as how we build the pipeline – We start with the view and then look for compatable Adapters -> Contracts -> Adapters -> View combinations to find a compatable pipeline for the requested view.

    – JackG

  3. In a previous post ( Extra, Extra – Read all about it! ) I mentioned an upcoming highly requested feature.

  4. We have gone through some naming changes with WinFX and .Net . And we have gone through a few on the

  5. It’s a great time to be a managed code developer! Our fearless leader, Jason Zander , has just blogged

  6. After all, our job is to make your life easier. I have received a *lot* of requests for a tool that can

  7. After all, our job is to make your life easier. I have received a *lot* of requests for a tool that can

  8. In this post I will be showing sample code (also found on our CodePlex site ) as well as an execution

  9. In this post I will be showing sample code (also found on our CodePlex site ) as well as an execution

  10. says:

    Hi Jack,

    Suppose I have an AddIn that exposes two completely independent interfaces (i.e. one for public consumption, and one to provide hidden plumbing to glue things together). If I activate the AddIn via one interface (which creates a new instance of the AddIn), is there any way to instantiate a second pipeline for the other interface to the existing instance of the AddIn? I guess I’m looking for the System.AddIn equivalent of casting an object reference.


  11. Vandermuelen, I’m not exactly sure I understand your question (e.g., hidden plumbing) but you may be served by our feature known as re-adapting. Check out the ContractAdapter class ( – JackG

Comments are closed.

Skip to main content