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