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

What Scenarios Let PartCreator Fail

Sep 17, 2009 at 4:27 AM

I have the following code in an exported part:

    <Import()> _
    Private userCreator As PartCreator(Of IUser)

This is failing on composition. I know this because the containing part appears in composition if I
comment out this import. The containing part is required, and therefore fails.
Perhaps I misunderstand something about how PartCreator works, but it's not obvious why this import

would ever fail.
Thanks for any insight into this. 
Sep 17, 2009 at 4:33 AM

More information on this...

Note that this was initially failing on composition. It was not giving the field access exception that in retrospect it should have given.

Apparently it is touching the implementation that fulfills IUser more than I expected. It is discovering at this point, not later when the instance is actually created, that there is an issue (another field access exception as I was actually exploring field access exceptions for an article) with the implementation of IUser. Not IUser, but the implementation. It would appear that it tried to fulfill those imports as it created the PartCreator.

Is this how it is supposed to work?

Could I request that the MEF team consider the ability to turn off or otherwise control stable composition in a future version of MEF? It's good for most apps some of the time, some apps all the time, and some apps none of the time.

I still want to understand this, but I have it working I think



Sep 17, 2009 at 5:40 PM

Hi Kathleen,

PartCreator imports are treated like Lazy imports - they guarantee validity at injection time. That means PartCreator.CreatePart() should never fail. If there's a chance that no part will be available to be created, you need to import the PartCreator with AllowDefault=true, just as for Lazy.

This is the essence of Stable Composition really - MEF guarantees that the dependencies it injects are valid.

I'm not sure about the field access - we are doing work now to resolve the issues surrounding injection of private members on Silverlight, stay tuned!

(It is possible we'll provide switches for stable composition in the future, however there is a way to do this today if you're determined enough - copy and modify CatalogExportProvider to create NonRejectingCatalogExportProvider, and initialize your container with one of these instead of a ComposablePartCatalog. Not recommended, but perhaps something to explore if you're really keen.)

Hope this helps!


Sep 17, 2009 at 6:05 PM

"PartCreator imports are treated like Lazy imports - they guarantee validity at injection time."

OK, that makes sense and is consistent with what I was seeing.