ansaurus

Question

Multiple exports with MEF does some really heinous stuff -- why, and why is it allowed?

Answer 1

A:

NOTE: The below guess has been confirmed incorrect.

If you have two exports, I'm pretty sure the import for each type of export will create a different instance. This is probably what caused your issues.

Dan Bryant 2010-04-20 19:29:13

that's a great point -- I would have expected a null exception earlier on, though. I'll stick some code in there to confirm what you've said, but I bet you're right. Do you know of any magic attribute I can use to force it to return the same instance?

Dave 2010-04-20 19:36:26

This is interesting. I put a breakpoint in the constructor of the plugin, and it only got hit once. Yet the code that calls into the other interface is working. So it seems that MEF is actually only constructing one instance, yet there is still something else going awry. The COMExceptions have come back after exporting the 2nd interface again.

Dave 2010-04-20 19:43:04

I browsed through the docs a bit, but I don't see anything obvious. You can export to a contract name and use that as your import for either interface rather than the type, but what you're really after is two imports asking for different contracts and getting the same instance. You could hack around it with a proxy object that implements ICandy1, imports ICandy2 and routes ICandy1 methods to the service implementation of ICandy2 : ICandy1.

Dan Bryant 2010-04-20 19:45:40

Hmm, if it's only constructed once, then not sure what's causing your issue.

Dan Bryant 2010-04-20 19:48:05

Answer 2

+2 A:

Having multiple exports on a single class is a perfectly normal use case in MEF. We do this all the time without problems.

Dan's remark is not correct. Unless you explicitly set a part creation policy on the import or export, MEF will prefer to reuse instances within a container rather than create multiple ones.

The COM exceptions you are seeing have nothing to do with MEF, as MEF itself is purely managed and doesn't use use any COM interop. You should take a look at the COM exception message and its stack trace. To make the debugger break when such an exception occurs, configure visual studio accordingly (Use the shortcut ctrl+d, e to see the relevant settings).

The erratic debugger behavior which you describe usually means that the source code and the compiled assembly do not match. Try cleaning out your bin folder, and check that the dependencies between your projects are project references rather than direct assembly references. Direct assembly reference do not properly trigger rebuilds if the source code of the dependency has changed.

Wim Coenen 2010-04-20 23:05:53

I'm glad to hear that this has nothing to do with MEF. The weird thing is that now I'm at home working on the same code (I tagged the version that threw COMExceptions), and it doesn't exhibit the same behavior *at all*. I will rerun the code at work and try to get a call stack tomorrow morning. Thanks for clearing up everything with the part creation policy.

Dave 2010-04-20 23:43:57

@Wim: Yes, I do use CTRL-D,E for when I need to really dig into exceptions. It's exactly what I did at the office when I was getting COMExceptions, but this is the first case where when the exception is thrown, it did **not** switch to the thread at the point where the exception was thrown!!! Really odd. I will do a full clean tomorrow. Hmm.. actually I will just RDP in now and see what's up.

Dave 2010-04-20 23:49:17

@Wim: do you have any other suggestions? I've cleaned, rebuilt, tested this on multiple systems, and this COMException **only** happens on one of my machines! I cannot get the code to stop executing at the point the COMException is thrown, regardless of my VS2008 options.

Dave 2010-04-26 19:05:11

@Dave: 1) Do you have the exception message of the COMException? 2) Do you use any native code? 3) Is your code multi-threaded?

Wim Coenen 2010-04-26 20:07:22

@Wim: I'll have to run this test again, but I recall the COMException not giving me anything useful. Stack trace is also useless. I do have native code because of a 3rd party DLL, but I don't think the offending code (multiple export) is using it. My code is multithreaded, but also not around the point of interest (as far as I can tell). I'll get back to you on this!

Dave 2010-05-05 01:13:47

ansaurus

tags:

views:

answers:

Multiple exports with MEF does some really heinous stuff -- why, and why is it allowed?

related questions