Unclear issue regarding discovery of parts.

Jul 14, 2011 at 11:24 AM
Edited Jul 14, 2011 at 11:26 AM

Hello all,

I have two questions:

1. Regarding how MEF discovers parts for composition, the bellow line is taken from MSDN:

- "MEF allows applications to discover and examine parts by their metadata, without instantiating them or even loading their assemblies", this leads me to believe that it does not perform any loading of assemblies, I think it is misleading, because the code clearly performs an Assembly.Load in order to load assemblies and scan them, my knowledge tells me that this cannot be done without Assembly.Load, or at least Assembly.ReflectionOnlyLoad. Maybe it is something I am missing in order to understand that line from MSDN. 

2. Does MEF contain built in support for caching of parts during different sessions (runs) of the applications? The problem I have is that I have a plugin based application, some plugins have a lot of dll's (I mean a lot), MEF without any filtering is loading them all, the idea was to discover parts without any configuration. In order to solve this problem, a caching system was created on top of MEF, it would be easier if MEF had build in support for that.

Aug 1, 2011 at 9:22 PM

The quote from the MSDN is correct, as MEF in no way relies on assembly loading, or even assumes that assemblies or types are even involved. The implemenation of the attribute-based programming model that we deliver in the box (exposed via theTypeCatalog et al) happens to eagerly load assemblies, but nothing in MEF activation or discovery assumes that, in fact, we are very careful to defer the activation of parts as much as we can. One can implement - and there have been examples of this - a TypeCatalog based on another metadata reader (e.g. CCI), and we will happily work with such a catalog.

Asnwering your second question, while MEF does not ship with any built-in caching, there have been several caching systems implemented on top of it, one of which is used by Visual Studio. In fact, the very reason that the ReflectionModelServices class exists is to support caching - if you examine it. you will see that you can implement a delay evaluating Type/Assembly/Directory catalog caching system based on those.

Hope this helps