Welcome to MSDN Blogs Sign in | Join | Help

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.

Published Wednesday, February 14, 2007 2:38 PM by JackG

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: CLR Inside Out: .Net Extensibility

Friday, February 23, 2007 7:56 AM by David Levine

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.

# re: CLR Inside Out: .Net Extensibility

Friday, February 23, 2007 9:46 AM by JackG

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

# Secret revealed

Thursday, March 01, 2007 12:35 PM by Jack Gudenkauf (JackG) WebLog

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

# Add-In’s (CLR and VSTA)

Wednesday, March 14, 2007 2:14 PM by Jack Gudenkauf (JackG) WebLog

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

# Side by Side CLR's in Process!

Tuesday, May 15, 2007 5:16 PM by Jack Gudenkauf (JackG) WebLog

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

# You asked for it (AddIn pipeline generator)

Thursday, January 10, 2008 4:41 PM by Jack Gudenkauf (JackG) WebLog

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

# You asked for it (AddIn pipeline generator)

Thursday, January 10, 2008 5:02 PM by Noticias externas

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

# Extensibility; Clients and Services calling each other

Monday, March 10, 2008 4:30 PM by Jack Gudenkauf (JackG) WebLog

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

# Extensibility; Clients and Services calling each other

Monday, March 10, 2008 4:40 PM by Noticias externas

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

# re: CLR Inside Out: .Net Extensibility

Thursday, October 16, 2008 4:42 PM by vandermeulen

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.

# re: CLR Inside Out: .Net Extensibility

Friday, October 17, 2008 2:34 PM by JackG

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

Leave a Comment

(required) 
required 
(required) 
 
Page view tracker