Feb 10, 2010 at 11:32 AM
Edited Feb 10, 2010 at 11:38 AM
It seems to me that MEF does not support loading assemblies into separate appdomains.
Unless I am wrong here, the system will be of limited value unless composition and re-composition permits the loading/unloading of assemblies.
Can anyone clarify this for me?
Suggesting "the system will be of limited value" because it lacks the ability to unload/load assemblies in separate appdomains could be misleading to those not familiar with MEF. After all the same could be said
about Prism and Unity because they lack this capabilitiy but would be just as far from the truth as it is for MEF.
For my purposes (http://ehr.CodePlex.com) there is nothing comparable to it and it does the job it is meant to do. If you are looking for unloading/loading assemblies in separate appdomains you'll want
MAF but be prepared for a steep learning curve (pipeline). If you don't have an application that must be up and running 24/7 the ROI will probably not be there. I have been part of Prism projects that have had over 30 modules
run without issue.
MEF has some distinct benefits and advantages (even over Prism and Unity).
1. Add-in support: years ago I attempted to provide Add-In support for the
Community (Advanced) Starter Kit (CASK) so that users could simply download a module, drop it in the folder and it would appear in their admin screen where they could install/uninstall it.
This worked great and as advertised until I attempted to build a module outside of the solution (using shared assemblies). I would get manifest errors and struggled with versioning issues (DLL hell) - I was forced to have each module have it's
own set of assemblies in its own bin folder which was quickly departing from my simple download into a folder and start using it concept. It was then I dabbled in MAF (MEF wasn't born yet) and the juice wasn't worth the squeeze. I abandoned
the concept. The concept is alive and well with MEF and my EHR application which in time will have 24 modules compliant with government regulations for "meaningful use" that folks can pick and choose as required for site certification.
2. Loosely coupled: Prism/Unity require interfaces to be registered with their implementations, e.g., Container.RegisterType<IFoo,Foo>(). This can be done in an xml configuration easily enough but not
as easy as MEF which will simply allow me to say - Import("FooContract",typeof(IFoo)) without requiring me to have a dependency on Foo - it simply needs to exist.
3. MEF is magical: back in the early days Glenn Block educated me on the "Voodoo" of Unity (I was new to DI - search for Voodoo in Unity forum). I have been a hardcore Unity fan since and won't
start my most basic application without it. But I have found MEF to be "magical" in that it can be "BuildUp" by Unity (continuing the dependency chain). Unity cannot BuildUp an object that has been dynamically instantiated
using Activator.CreateInstance() this has forced me to come up with work-arounds such as having foo implement an IBuildup inteface which required a method in foo that did a BuildUp(this). The fact that MEF, in the magical way in
which it dynamically creates instances, can be built up by Unity opened a big door for integrating MEF, Prism and Unity (as I have done in my EHR project). I've been disconnected from MEF for a year or so because it is not yet released
(clients are funny that way ;) but for my own project the foundation will be based on it so I get to play now.
Try building an Add-in without it and you'll quickly appreciate its raw power and simplicity.