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

MEF error handling is obscure

Dec 31, 2009 at 11:40 PM
Edited Dec 31, 2009 at 11:46 PM

I've recently started a mid-size project using MEF, and in general I'm impressed with the approach taken and it's ease of use - but having the odd issue here and there...


Missing export

One item has me confused however: I accidentally forgot to export a class - generally no big deal, however the error message is surprisingly garbled and confusing:


"no valid exports were found that match the constraint '((exportDefinition.ContractName="Shell.MainShell") && (exportDefinition.Metadata.ContainsKey("ExportTypeIdentity)..."

(thrown from ExportProvider.cs, line 108)

The main class (Mainshell) was correct - but nowhere in the message does it mention the actual import that's unsatisfied (ExportTypeIdentity has nothing to do with my class), leaving me dazed and confused as to where to look to fix the problem.

I believe that the correct message should be something similar to:

"The import 'IMenuButton MyMenu' in class Shell.Mainshell (line number?) can't be found

Too many exports

The error message for too many items appears to be identical.  There's a switch option for 'too many items' in the ExportProvider code - however it doesn't appear to be activated correctly.  In short, the same "no valid exports were found" message appears.  In this case I think a more meaningful message would be:

"There are too many exports for 'IMenuButton MyMenu' in class Shell.Mainshell (line number?).  Exports are:

   * class / export

  * class / export (etc)"


Some improved error handling would make my New Years day morning that much more satistfying... ! (HNY, MX to all!)

Jan 1, 2010 at 10:25 AM
Edited Jan 1, 2010 at 10:25 AM

HI David

Glad you are finding MEF easy to use.

What you are seeing is actually a feature of MEF though it may not be obvious and it is totally understandable why you might think it is broken. I can assure you it is not. The feature is called Stable Composition, which you can read about here:

MEF actually rejects parts with missing imports, meaning they are ignored as if they did not exist. The reasoning for this is trying to create the part will only yield an exception, and will often result in corruption of the state of the container. In an open-system where 3rd party extensions are showing up, you don't want some broken extension (missing a dependency) bringing down the system. MEF knows that the part is missing a dependency so it will reject it. The part in this case that is getitng rejected is MainShell as a result of the missing dependency, which is by design.

If you are in Visual Studio 2010, we actually trace rejection messages to the output window. If you check your output window, I am guessing you will see a message saying something like "MainShell has been rejected". We output to a TraceSource thus you can also track rejection messages in a deployment environment by editing your config file.

We have a stand alone tool called  MEFX that you can use for diagnosing rejection issues. You can read more about it here and here

Hope this helps and Happy New Year :-)


Jan 1, 2010 at 11:29 AM

Addressing the "Too many exports" part of your question, that is also related to stable composition.

Let's say you have an OrderProcessor that imports an ILogger, and there are mutliple loggers present in the catalog. When you go to resolve OrderProcessor from the container, It will be rejected. The reasoning is basically the same, OrderPart needs a single logger, but the catalog has 2. MEF doesn't know which one to choose, so instead it rejects OrderPart.

There are several options for how to deal with finding a single in the presence of many. Daniel covers the main approaches in this post: