MEF - Library separation

Sep 30, 2008 at 11:21 PM
Hi!
I would like to point to one issue (which I'm currently working on in my "Omlette" framework [the name is not coincidence :)]) about library separation. Please consider the following scenario:
- I have two plugings that have theirs on library dependency (let say Plugin1 uses RefLib ver 1.1 and Plugin2 uses RefLib ver 1.2)
- RefLib do not have strong name
- I'm using "AggregatingComposablePartCatalog" with two "DirectoryPartCatalog",  for "ver1" and "ver2" directories where plugins have also dependent assemblies which are RefLib1 and RefLib2.
- I use the following order: Catalog.Add(new DirectoryPartCatalog("ver1", false)), Catalog.Add(new DirectoryPartCatalog("ver2", false)).
- Let say that my Plugin1 and Plugin2 export method displaying dependent assembly version.
When I execute these methods I'll receive assembly version that was in the first "ver1" directory, if on the other hand I change the order of directories, adding "ver2" as first I will receive assembly version from this folder.

I'm sure that you are aware of this since it is know issue (one solution is to require that all plugins to use stongly named assemblies or by using AppDomain for loding plug-ins)
But did you guys think about any solution. For "Omlette" I don't want to require from plugins to reference only assemblies with stong name. I was thinking about idea simillar to java's ClassLoader, at least with library separation (since unloading assembly isn't possible without unloading AppDomain).
Maybe someone knows any other solution? (I'm also curious if in future it will be available in CLR.)

Regards!

Coordinator
Oct 1, 2008 at 7:22 PM
I'm not really sure what you're asking for here.  Can you be more explicit about what you mean by "similar to java's ClassLoader"?

It doesn't sound like this is something we are going to address with MEF.  MEF isn't going to change the way assemblies are loaded or located in .NET.  It might be best to use strong names as you suggested.

Daniel