Lazy<T, TMetadata> incorrectly instantiates component when only querying for metadata

[tillig]

From @sherland on June 25, 2015 12:42

Please see repro at http://stackoverflow.com/questions/31045686/bug-in-autofac-mef-integration-instantiates-component-when-only-querying-for-me

Copied from original issue: autofac/Autofac#651

[tillig]

Now that I've come out of the .NET Core haze, I'm getting a chance to look at this.

The bug appears to be due to the way we wire up Lazy<T, TMetadata> support not quite working with the way we tie MEF exports to each other.

Slight detour into the weeds:

In adapting MEF components to each other, we basically have to say "Export type Foo has ID 123 and importing type Bar takes a Foo, so tie that import to export ID 123." (Basically.) You can try following the code starting here. Every time you see a reference to a UniqueService object, that's mapping a type/export to a specific unique ID. Which is to say, it's not "typed" anymore. There are reasons for that which I won't get into here because it's not relevant.

Point being, this has the unfortunate side effect that, while it works for most things, it means when a property on an object that runs through Lazy<T, TMetadata> isn't going to make its way into the LazyWithMetadataRegistrationSource as a typed service, so the source is going to bypass it entirely It instead will fall back to some default behaviors and instantiate the object automatically, which is what this whole issue is about.

A workaround is to register the types consuming Lazy<T, TMetadata> with Autofac directly:

// After you register the part catalog, do this:
builder.RegisterType<ServiceConsumer>().PropertiesAutowired();

I'm not sure how to resolve this from a MEF integration standpoint at this time. I'll have to keep looking at it.

[tillig]

Right now it looks like the best I can do is add a failing (skipped) unit test to try and verify the behavior when we get a chance to fix it. There are a couple of other issues here (like the one about allowing open generics) that makes me wonder if the MEF integration either needs some TLC and major overhaul or has potentially reached its limits given it's a convenience bridge rather than a 100% feature-for-feature mapping from MEF to Autofac.

If you have a PR for this, we'd be happy to take it.

[tillig]

I updated the Autofac + MEF docs to include this as a known issue.