Share via

MEF and System.AddIns

  • Article

Several people asked about the relationship between MEF and the technology in System.AddIn namespace. The answer is that these two are independent and complementary features. MEF is a primarily a composition engine. System.AddIn is an add-in activation and isolation technology. MEF’s engine will be able to compose objects that are simple CLR object, COM and DCOM components (more precisely managed proxies to these components), remoting proxies, and finally System.AddIn add-ins.

 

The following is roughly how we see the basic “architecture” (conceptual diagram) of these technologies. As you can see on the diagram, the composition engine works on abstract representations of components currently called ComponentBinders. The composition engine is not concerned with how the parts are actually implemented or activated (COM, simple new operator, or System.AddIns activation). Its only concern is to inspect the binders for dependencies they need (imports) and objects they can give (exports), and provide “matchmaking” services for the binders (blue arrows on the diagram).

 

Comments

  • Anonymous
    June 13, 2008
    Krzysztof, I absolutely love the work you have done. It's so important to our industry. Making the consumption of others work a PLEASURE rather than a burden is quite an important area to focus on. Getting them to do it however (grin)... In that spirit, I have focused extensively on Domain Specific topics now for... A while. I care mostly about assisting other developers to achieve more, and this often comes down to how much their work can be leveraged by others and how 'consumable' it is. In my opinion this is just one of many small steps to move people to the big idea of 'it's all about the domain stupid!'. Although your work can be seen in a broad scope, I view it as effective to the software leaders attempting to hide complexity and expose simple abstractions for 'their domain'. Have you reviewed the work in progress by Martin Fowler and his upcoming DSL book? I especially am fond of his chapter on what he has termed 'Expression Builder'. I would of called it 'Fluent Domain Specific Language API Design' but that is why he defines things, not me. He clearly delineates between what has become a kind of de-facto stylistic approach (most notably in Mock frameworks today)  vs. more traditional OO style in exposing capabilities. Linq definitely has elements of this via as well in it's non-sql styled api target.where(x=>x.IsCurrent()).Select..... For others who may be interested it can be found here: http://martinfowler.com/dslwip/ExpressionBuilder.html He defines this as: "A layer that provides a fluent interface over a regular API. APIs are usually designed to provide a set of self standing methods on objects, ideally these methods can be understood individually. This is in conflict to a fluent interface which is designed around the readibility of a whole expression, which leads to methods that make little sense individually. An Expression Builder provides a fluent interface as a separate layer on top of the regular API. This way you have both styles of interface and the fluent interface is clearly isolated, making it easier to follow." I find myself now instinctively exposing my API access to my work in this style. Thoughts? Kind Regards, Damon Wilder Carr http://damon.agilefactor.com

  • Anonymous
    June 13, 2008
    The comment has been removed

  • Anonymous
    July 16, 2008
    The comment has been removed

  • Anonymous
    October 06, 2008
    Does anyone understand Damon Carr's post from July 17, 2008 2:44 AM? It's completely incoherent to me.

  • Anonymous
    December 02, 2008
    sorry about that... I either needed much more content or much less. I tried to compromise and ended upp ot being as clear as I would have liked (GRIN). Long story short: DSLs are almost an assumed future ad I cannot see the tools being 'just graphical' - think UML but for 'your company'. DSLs will be graphical to a point and textual for delivery with integration. Damo

  • Anonymous
    May 20, 2009
    I don`t really understand how MEF and AddIns can work together if MEF exposes parts through CompositionContainer and AddIns finds plugins by calling AddInStore.FindAddIns(...)?

  • Anonymous
    May 20, 2009
    There are many ways to do it. I would start with the simplest: write a custom ExportProvider that activates add-ins using AddInStore.FindAddIns and returns them as exports. Glenn Block promised to write a sample showing how to do it, but he did not say when :-)

  • Anonymous
    September 04, 2009
    I don't see how they're complimentary either.  Visual Studio would have the most comprehensive set of requirements for add-ins, as far as versioning and so forth goes, and yet Visual Studio will be using MEF, not AddIns.  ??? Why would we want two ways to do add-ins, anyway?  We should have one library to do this, with different options for how it can work based on app needs.