Share via

CLR Inside Out: .Net Extensibility

  • Article

(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

  • Anonymous
    February 22, 2007
    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? Thanks.

  • Anonymous
    February 23, 2007
    The comment has been removed

  • Anonymous
    March 01, 2007
    In a previous post ( Extra, Extra – Read all about it! ) I mentioned an upcoming highly requested feature.

  • Anonymous
    March 14, 2007
    We have gone through some naming changes with WinFX and .Net . And we have gone through a few on the

  • Anonymous
    May 15, 2007
    It's a great time to be a managed code developer! Our fearless leader, Jason Zander , has just blogged

  • Anonymous
    January 10, 2008
    After all, our job is to make your life easier. I have received a lot of requests for a tool that can

  • Anonymous
    January 10, 2008
    After all, our job is to make your life easier. I have received a lot of requests for a tool that can

  • Anonymous
    March 10, 2008
    The comment has been removed

  • Anonymous
    March 10, 2008
    The comment has been removed

  • Anonymous
    October 16, 2008
    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. Thanks.

  • Anonymous
    October 17, 2008
    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 (http://msdn.microsoft.com/en-us/library/system.addin.pipeline.contractadapter.aspx). - JackG