Modularity MEF and resolving on-demand

Topics: Prism v4 - WPF 4
Apr 12, 2012 at 2:59 PM

A quote from Chapter 4: Modular Application Development


"It may also ask the container to resolve an instance of a type it needs."
What is the best way to achive this?

I have a concrete example of this worked out.
It is a small extension on top of the Modularity with MEF Quickstart.
It can be found here:!134&parid=FD27ECF1A68DC889!131

Summary of the changes: 
- new assembly LibforModuleE with Class1.cs, has [Export] attribute
- ModuleE references Class1 in LibforModuleE.dll (LibForModuleE.dll is copied along ModuleE in it's post-build step)
- Class1 logs and therefore [Import]s the ILoggerFacade
- During the initialisation of ModuleE, a call is made into Class1 (ModuleE.cs line 54)
- Since the ILoggerFacade never got imported in Class1, the application crashes during the initialization of ModuleE
(Class1.cs line 15)


- I cannot add a hard reference from the main ModularityWithMef.Desktop assembly to the LibForModuleE assembly
(then I could - in ConfigureAggregateCatalog - add that assembly to the AggregateCatalog ) 
- the LibforModuleE.dll is not in the DirectoryModules sub folder
(then the DirectoryCatalog would have picked it up) 

These 2 solutions would void the on-demand aspect of ModuleE (and its dependencies)

What is the canonical way of getting the ILoggerInterface imported into Class1,
in other words: how to ask the container to resolve the ILoggerFacade? 

Bonus question: next to importing the necessary ILoggerFacade into Class1,
it there a way to add Class1 itself into the container during the initialisation of ModuleE,
so that some other class (e.g. Class2) can then import an instance of the exported Class1?

Thanks in advance!

Jan Verley






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;
            this.catalog.Catalogs.Add(new AssemblyCatalog(typeof(Class1).Assembly));


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,

Agustin Adami

Apr 13, 2012 at 3:20 PM


I was aware of the root of the problem: the non-discovery by MEF of Class1.

Your proposed solution works indeed!
I was not aware that
- the AggregateCatalog was available as a part in the Container (it feels a bit circular/recursive)
- adding types to the AggregateCatalog was possible/made sense at this moment, long after the bootstrapper had finished.

1 final question: 
Is it possible to avoid the dependency on the ServiceLocator to retrieve the class from the container and use a more pure MEF method?
And if not, is the use of the static ServiceLocator.Current not an issue when writing unit tests?
As far as I understand, this makes it impossible to inject the dependency?



Apr 13, 2012 at 6:40 PM

Hi Jan,

Based on my understanding you will be able to retrieve the Class1 from the container using MEF conventional methods from any class in the module's project as long as it is resolved after the library assembly is discovered (i.e. when the module's constructor completes). For example any view or view model classes which have a dependency to Class1 should be able to resolve it without problems.

Although, this will not be possible if you need to resolve a class which contains a dependency to the exported Class1 in your IModule's class; as far as I now, for this case you will have to do it through the ServiceLocator. Also, if you wish to test the aforementioned module class using the ServiceLocator will involve having an additional dependency to mock (i.e. the service locator).


Agustin Adami