This project has moved and is read-only. For the latest updates, please go here.

Loading MEF exported assemblies into memory

Oct 11, 2009 at 3:37 PM

I recall reading long ago that MEF does not need to loda an assembly into memory in order to read metadata of an exported class. This should be an advantage over using reflection to examine a class within an assembly.

Is that correct? I can no longer find anything in the documentation that states this.

Thank you.


Oct 11, 2009 at 6:01 PM

Technically that is true in that MEF allows you to create custom catalogs that persist the part information. Because MEF is inherently lazy, the types don't actually have to get loaded until instances are actually created. You can query the catalog in a lazy manner using GetExports, or import lazy collections to allow you access exports in this manner.

Although MEF supports this, we don't ship an implementation of a cached catalog today, though this is something we are looking into in the future. If you look in Preview 7 you wll see a cached catalog sample. This sample contains a catalog which caches the results of reading assemblies, and then uses that cache whent he app is restarted. The cache is actaully an emitted assembly which contains parts that will do the loading on demand. This is just illustrative of one path for caching, one could also explore having an xml file for example which contains the cache.

If you are interested in authoring your own, you'll want to look into our Reflection Model Services api (System.ComponentModel.Compositioon.ReflectionModel). ReflectionModelServices allows you to define your own programming model that loads parts in a lazy manner. It gives you the hooks to plug in your own mechanism without having to design a new model completely from scratch.

Hope this helps



Oct 12, 2009 at 5:18 AM


Thanks for the clarification.

Is it correct to say that Lazy Loading allows MEF to open an assembly quickly in order to read metadata without loading that assembly into memory? Is this an advantage (faster, fewer resources) over the way Reflection currently works in .Net?

Thank you.



Oct 12, 2009 at 5:27 AM

Yes, lazy loading allows this. The advantage of this is the assembly never actually gets loaded unless/until it is used, which improves startup time, but further conserves resources. In Silverlight this means you could delay the download of a XAP until you need it, something desirable. As far as the benefits of caching, it depends on how big the app is and how many parts there are. Visual Studio for example has it's own cached catalog because there are thousands of components. Through utilizing a cache, VS only loads the components that are needed on demand, rather than all at once.



Oct 12, 2009 at 5:39 AM


I was thinking of a scenario in which you had several dozen Exports that matched an Import contract but you only wanted your application to use one of these, based on some Metadata criteria (maybe something in the user preferences matches a metadata value). MEF should be able to examine the metadata of dozens of exports very quickly because it doesn't need to load any of these 'Export' assemblies into memory in order to read the metadata.

With the current version of .Net (without MEF), we would probably use Reflection to accomplish this. But I believe Reflection would be far slower because it would need to load each assembly into memory just to see if the matching class met the expected criteria.

I'm writing an article on the advantages of MEF I want to state this as an advantage that MEF has over Reflection, but I don't want to misrepresent either MEF or Reflection. Is the reasoning above correct?



Oct 12, 2009 at 5:45 AM


This is definitely a scenario we designed MEF to support. The primary reason metadata in MEF exists is for delay loading. HOWEVER out of the box, our attributed model does use reflection. Thus if you use our Directory catalog, then you are reflecting. However if you use ReflectionModelServices as I described you could create a catalog that has parts which are lazy, they only contain exports which are not yet attached to live types. Upon accessing them then the types are loaded. You can basically think of them as lazy wrappers.  As I mentioned, if you look in the caching sample you will see ReflectionModelServices being used, albeit in a very sophisticated fashion.

So again, MEF supports what you are asking by design, but you don't have a default implementation out of the box.

Does that make sense?

Oct 12, 2009 at 5:50 AM

Got it now.

My assertion (MEF is faster than reflection) is only true if I write a custom catalog. Using the default implemenation, my assertion is not correct.

Thanks for taking the time to clarify this for me.



Oct 12, 2009 at 6:01 AM

No problem Dave.

Just as a side note, in the future we are looking into shipping one in the box. No promises, but we are evaluating the possibility. ;-)

May 4, 2010 at 9:15 PM
I know this is very old topic. But I think this is a nice one to understand what is behind MEF and differecences with reflection... So, we have now MEF as final release with .NET 4.0...I have two questions about the final situation... First one is; What is the final status of cached catalog concept...All current catalogs have this cached approach, or should we implement our own? Second is about MEF vs. Reflection...As I know that MEF just encapsulates some reflection operations by default implementation. So which current catalogs have lazy loading?
Oct 4, 2010 at 7:37 AM

Hey Glenn, I'd also be interested to know what the state of such a "caching catalog" is. The idea of a container that can read metadata from assemblies without loading them is very appealing, espescially if it can be given a folder of assemblies to load.


Oct 4, 2010 at 7:46 AM

Hi Charles

We did ship a version of a Cached catalog in our MEF samples (for the full framework not SL). That one is a pretty advanced and emits IL for caching the catalog info. However the ReflectionModelServices API I mentioned was designed as a general mechanism for caching. You could use it to build a cache to an Xml file for example.

As to the status of getting a cached catalog in the box, that is something we discussed before I left the team. I am not sure however where it has ended up on the backlog for V2.