Apr 12, 2012 at 8:59 PM
Edited Apr 12, 2012 at 9:00 PM
We checked the sample you provided, and we found that the cause of this problem is that the parts of the
LibforModuleE.dll are not being discovered by MEF, and therefore you won't be able to resolve an instance of
Class1 from the container.
Hence, you might have to discover the parts in your LibforModuleE.dll assembly explicitly.
As you mentioned, this could be achieved using the AggregateCatalog
class provided by MEF. In my opinion, to avoid loosing the on-demand aspect of
ModuleE (not overriding the ConfigureAggregateCatalog), you could retrieve the
AggregateCatalog instance as a dependency in your ModuleE's constructor. This way you could register the missing parts from the
LibforModuleE.dll when the module is loaded. An example of this could be like in the following code snippet:
public class ModuleE : IModule
private readonly AggregateCatalog catalog;
public ModuleE(IModuleTracker moduleTracker,AggregateCatalog catalog)
this.catalog = catalog;
Once the part is added to the catalog you will be able to retrieve the exported types from the container. For example in
ModuleE, Initialize method or from other class that requires it.
To retrieve the desired exported class you could access the container via the
ServiceLocator. For example like this:
public void Initialize()
var testInstance = ServiceLocator.Current.GetInstance<Class1>();
Note that if you don't retrieve the class from the container, the imports will not be satisfied.
Additionally for more information you could check the
MEF Programming Guide.
I hope you find this useful,