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

Debugging Problem with Multiple Exports Incorrectly Found

Jun 4, 2009 at 11:41 PM

This is Preview 4 still. I'm trying to stabilize before i switch.

I've just spent most of this afternoon beating my head against this problem. I'm not going to try to repro the whole problem here, although I can send it. I'm mostly concerned with a strategy as I find I'm wasting a lot of time debugging.

I'm creating an aggregate catalog and a parts list When everything is ready, I create the container, add hte parts the batch and compose.

I'm getting an error that there are multiple parts for one interface contract (that expects only one).

- I searched the project for this interface and find it is explicitly exported only one place. So, I must be adding the assembly multiple times, or I must be adding it as an explicity part

- I check the aggegate catalog and find only the anticipated directories (stopped in the debugger right before the compose)

- I check the aggregate catalogs parts list and find the problem interface existing only once.

- To be sure I'm not overlooking something, I copy to NotePad and search for a substring of the interface name

What else do I check for?


I've checked the directories and

Jun 5, 2009 at 4:22 PM

Sorry for the spare text at the bottom. I just structured the message badly.

Here's an update. I'm going on two days on this bug, which I'm sure at root is something very simple and dumb. So, its fair to say I'm frustruated. BUt it is solved. I'm very interested in understanding how to better debug MEF, so I'm including some process details, in addition to the solution.

I had a different assembly that was included twice in the catalog. I've changed my process so an assembly by the same name is not loaded twice. This will hopefully avoid some problems. It's ugly, I'm just keeping an array and checking it and evalutating directories on my own - using AssemblyCatalogs not directory catalogs. This turned out to be a dead end for this particular bug though. It's not a multiple assembly problem.

I check to see what the actual return types of the multiple exports was and to my surprise found that one of the exports returns a value, as expected. However, the other returns null (a fragment from the debug window is below. OK, this was unexpected, so I thought about how MEF could possibly do this. I was quite certain that nowhere was I exporting by interface as I'd searched the project several times. However, what if one of hte declarations I'd looked past in the FindInFiles results was an export instead of an import? Sure enough, my most recently added code in fact contained a typo with an Export where an Import should have been.

What could I have done, other than not making a stupid mistake, to make this process easier? Add to the pattern above actually retrieving the exports and looking at their type. This also woudl have been a faster way than the FindInFiles search to ascertain if an unexpected class was exporting the interface. And of course check the directory per my mistyped note at the bottom. I'll work on a blog post on this.

? _compositionContainer.GetExports<IExportingCompositionContainer>()<font size="1">

Count = 2

[0]: {System.ComponentModel.Composition.ExportServices.StructuredValueExport<AppVenture.Common.IExportingCompositionContainer,System.Collections.Generic.IDictionary<string,object>>}

[1]: {System.ComponentModel.Composition.ExportServices.StructuredValueExport<AppVenture.Common.IExportingCompositionContainer,System.Collections.Generic.IDictionary<string,object>>}

? _compositionContainer.GetExports<IExportingCompositionContainer>()[0].GetExportedObject()


[AppVenture.Common.ExportingCompositionContainer]: {AppVenture.Common.ExportingCompositionContainer}

BaseCompositionPath: null

? _compositionContainer.GetExports<IExportingCompositionContainer>()[1].GetExportedObject()




Jun 5, 2009 at 6:49 PM

Sorry about this experience. Unfortunately something like this can be extremely difficult to debug, the missing Export error can be equally if not more difficult to debug as well.

One thing I'm thinking about writing is a debug visualizer for catalogs that will allow you to browse all the exports and even filter via export names which would have hopefully been beneficial in helping diagnosis the problem you ran into.

We are open to any ideas you or anyone else might have to help improve the debugging story in MEF.

Jun 5, 2009 at 7:03 PM

I wonder how deep you could you go ln a Visualizer. I havne't looked at the Visualer story in 2010. Are they still modal?

I wonder if you could have three tabs - normal, missing export issue, multiple export issue. Then on the back to tabs, walk through common debugging issues.

Is that a good place for it? probalby not. Do we need a really easy to find MSDN/whatever entry that's going to come up in search issues for key phrases like Debugging MEF? absolutely. Is it possibly a place for it where people can quickly find notes? maybe.

So, I'm a novice MEF user and I get these good exception messages to get me started. I know that a particular contract is missing or redundant. What do I do next and how do I know to do it?

For me the first pain I'd want the Visualizer to help with is the enumerable of exports when what I want to see is the contents - the exported objects not the export.  If I've got a lot of exports (more than one) that's painful.  That's not even catalogs, but it would be helpful.

I'd also like as much informaiton on the catalog as possible. I separately asked about assembly and directory catalogs not knowing their locations so we can check for redundancy. For early users, files redundantly placed in two directories will be one of the most common problems I suspect.

I haven't look at visualizers in 2010, but what great options we'd have if they are fully WPF and MEFized. I'm guessing I need to be patient.