Attributed programming model + delay loading?

May 25, 2009 at 4:34 PM
Edited May 25, 2009 at 4:34 PM

My goal is to use the attributed programming model (APM) without having to load all of the assemblies in my application when the application starts.  The problem that I see is that the out-of-the-box catalogs (namely, AssemblyCatalog, DirectoryCatalog, and TypeCatalog) seem to require that the assemblies for all APM-attributed types to be loaded.

A few approaches that I've considered:

a) Create a custom catalog that uses Cecil or CCI instead of reflection.

b) Use Cecil or CCI but leverage existing infrastructure by building a TypeCatalog where the Types are custom implementations of System.Type (similar to what's described at

c) Create a custom ExportProvider that uses Cecil or CCI to discover and return exports.

d) Generate cached information and somehow provide this information to MEF.  gblock indicated that this would be "very easy" in an earlier thread (, but I'm not seeing the mechanism for doing this in preview 5.

All approaches (except maybe d) seem like a lot of effort.  It seems like this would be a very common scenario, particularly in medium to large size applications, so I'm thinking that there must be some easier way to do this or this has already been done by somebody else.

Any suggestions?

May 26, 2009 at 4:34 PM

a) An interesting approach but would still require you to load and reflect over all the assemblies at startup, although you can at least unload all the assemblies when you’re done reading. I see this as more of a replacement for using Reflection then a delay loading model.

b) I think this may be going a little too far off track, while it may be an interesting approach I don’t know it if it buys you much.

c) This is equivalent to a combination of a) used with our CatalogExportProvider and if you were going to go this far I would suggest you stick with a).

d) This is the approach where I think you could gain the most. In an earlier CTP we had a version of caching but due to some limitations and time constraints we decided to pull it from MEF v1. We however did add some API’s (see ReflectionModelServices) that allow someone to more easily implement a caching story. Internally we have a prototype for caching and I believe we plan on posting that at some point, although I’m not sure when or where exactly.

We realize that caching is an area we need to invest some time on and it is on our V.Next list.


May 27, 2009 at 4:06 PM

Thanks for the comments.  For d), I wanted to clarify how ReflectionModelServices could be used to implement a caching approach.  Is the idea that I would cache enough information to build the parameters for CreateExportDefinition, CreateImportDefinition, and CreatePartDefinition, and then I would implement a custom ComposablePartCatalog that would implement the Parts property by returning the ComposablePartDefinitions that I created via CreatePartDefinition?

Also, I was curious how Visual Studio 2010 uses MEF and delay loads assemblies.  Visual Studio uses the attributed programming model, but given how Visual Studio has always strongly emphasized the importance of delay loading packages, I'm assuming that Visual Studio is not using DirectoryCatalog and AssemblyCatalog since they eagerly load assemblies.  What does Visual Studio do and can I easily do the same thing?  Is Visual Studio doing approach d) via the internal caching approach that you mentioned?

May 27, 2009 at 4:51 PM

Hi @Isaac

  1. Using the caching API allows you to create parts directly. Here's a sample of how to use the API for doing a simple poco MEF api. The sample is not for caching, but it illustrates how you use the API. See the code here: I am planning to do a blog post on this,
  2. Yes you would wrap the API in a custom catalog most likely, as is shown in the sample code.