Is MEF an all-or-nothing affair?

MEF is designed to let you easily load plugin assemblies. If you have control over the plugins (by which I mean that you can add MEF export attributes) then there is no need to keep your own plugin loader which uses reflection. MEF does all that for you That being said, "mixing and matching" MEF with other technologies is certainly possible.It sounds like your problem is that if you use your own plugin loader, you don't add those plug-ins to the MEF container.

As a result, you get a CompositionException for parts which try to import the selected plug-in To add a plugin that you loaded with your own code to the MEF container, you can use the ComposeExportedValue like this: container. ComposeExportedValue(selectedPlugin) edit: I see what you mean now by "all or nothing". Your problem is that in order to be able to import parts with MEF, you also need to construct the object with MEF.

This problem then cascades to the object which normally created that object, etc. All the way to the application root To avoid this "all or nothing" effect, you can compromise by exposing the MEF container as a global variable (i.e. Static field). That way, classes can access the MEF container and pull exports from it, e.g. By calling Program.Container.

GetExportedValue() in the constructor edit2 : If you have an object that was not constructed by MEF, then there are two ways to add it to the container The first is to call container. ComposeExportedValue(myObject) The second is to return the object in a property getter, and then mark the property itself with an Export(typeof(SomeType)) attribute.

MEF is designed to let you easily load plugin assemblies. If you have control over the plugins (by which I mean that you can add MEF export attributes) then there is no need to keep your own plugin loader which uses reflection. MEF does all that for you.

That being said, "mixing and matching" MEF with other technologies is certainly possible. It sounds like your problem is that if you use your own plugin loader, you don't add those plug-ins to the MEF container. As a result, you get a CompositionException for parts which try to import the selected plug-in.To add a plugin that you loaded with your own code to the MEF container, you can use the ComposeExportedValue like this: container.

ComposeExportedValue(selectedPlugin); edit: I see what you mean now by "all or nothing". Your problem is that in order to be able to import parts with MEF, you also need to construct the object with MEF. This problem then cascades to the object which normally created that object, etc. All the way to the application root.

To avoid this "all or nothing" effect, you can compromise by exposing the MEF container as a global variable (i.e. Static field). That way, classes can access the MEF container and pull exports from it, e.g. By calling Program.Container.

GetExportedValue() in the constructor. Edit2: If you have an object that was not constructed by MEF, then there are two ways to add it to the container. The first is to call container.

ComposeExportedValue(myObject);. The second is to return the object in a property getter, and then mark the property itself with an Export(typeof(SomeType)) attribute.

1 Great, I'm glad that my current implementation matches yours exactly, as far using the names exposed by the plugin interface. It's working great. But still -- this does seem all or nothing.

For example, as I convert more and more to MEF, I find more and more null references. And this makes sense because so many modules require the shared libraries, and so obviously those need to also be loaded by MEF in order to resolve the dependencies. I'm not sure why I had expected otherwise -- I guess it's because MEF just seems so magical, and you know how that goes.

:) – Dave Apr 20 '10 at 23:54 Looks like you commented on my answer before I edited it. I tried to roll back to the original, but apparently revisions are not stored if done quick enough after posting the answer :-/ – Wim Coenen Apr 21 '10 at 0:08 @Wim: thanks for the updates to your answer! I am actually going to just use MEF as a plugin loader replacement.

And for those that aren't loaded by the catalog, I'll give your method a try, but I thought there was an AddPart method that you use to add into the container? – Dave Apr 21 '10 at 0:15 @Wim: It's as if we're playing post tag here! :) Thanks for the response, I think you understand what I am getting at here with the "all or nothing" comment!

So yes, I guess I could do something like what you propose with the MEF container, but wouldn't you use something else to resolve this, like CSL? – Dave Apr 21 '10 at 0:17 @Dave: making the MEF container globally accessible essentially turns it into a service locator. Common Service Locator just has the advantage that you put an abstraction between your code and the container, so that you don't get a direct dependency on MEF everywhere.

That might be important if your code needs to be usable with other IoC containers and applications. – Wim Coenen Apr 21 '10 at 0:28.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.