Child Lifetime Scope - Lazy<T, TMetadata> Resolved Multiple Times

[oh-yeah]

Describe the Bug

Dependencies with Interface-Based Metadata are resolved multiple times when resolved from a child lifetime scope when the confgurationAction is supplied.

Steps to Reproduce

1. Register dependencies with interfaced-based metadata
2. Build the container
3. Begin a child lifetime scope using a configurationAction
4. Resolve the instances as an IEnumerable<Lazy<T, TMeta>>

• Instances are resolved twice using the standard container
• Instances are resolved three times using a multi-tenant container

using (var scope = container.BeginLifetimeScope("child", b => {}))
{
     // DUPLICATE DEPENDENCIES RESOLVED HERE
     var deps = scope.Resolve<IEnumerable<Lazy<IDependency, IMeta>>>();
}

Reproduction Repo: https://github.com/oh-yeah/Autofac-metadata-issue

Expected Behavior

Resolution to be consistent across Lifetime scopes.

Exception with Stack Trace

No exception thrown

Dependency Versions

Autofac: Version 6.x

Autofac.Mef: Version 6.0

Additional Info

[tillig]

Verified, but I'm not sure what to do about it at the moment.

I do see that we treat the two BeginLifetimeScopes slightly differently and that registration sources that are set as IsAdapterForIndividualComponents will get copied into the lifetime scope only in the case where there's a configuration action. I know we've had a lot of challenge in the past with how registration sources get dealt with in child scopes.

I also see both MEF sources are marked as such (one, two), which explains why we're seeing the symptom - the registration source is getting hit twice, so you see twice the dependencies.

I gather one of those things needs to change - either the handling of registration sources in configured child scopes or the setting for IsAdapter... on these sources, but I'm not sure which at this moment. Likely the latter, but I haven't thought it through entirely and I'm off to some day job stuff so I won't get a chance.

@alistairjevans or @alsami do you have any off-the-cuff thoughts on which spot would be better? (I'm guessing the easiest spot to fix/test would be in this MEF repo.)

[alsami]

@tillig I'd guess that this repository is the right one, if the problem is really only related with the extension. Which is the case, if I understood correctly.

[alistairjevans]

I'm on vacation right now, so no easy access to code, but I will say that the need for IsAdapterForIndividualComponent became way less important when we moved to v6 and a load of the internal registration stuff changed so sources usually didn't need to specify it. It was largely left behind for compatibility with existing libraries, although this issue seems to indicate it may have backfired in some places.

I'd argue you could probably just set IsAdapterForIndividualComponent to false here and see what happens....

Also worth raising an issue in the Core repo to address this more completely maybe?

[tillig]

Yeah, I'm in hardcore head's down mode at work which is why I didn't just dive in right here. But I agree, I think just trying out this repo with IsAdapterForIndividualComponent as false for grins and giggles would be a good way to go. I can throw something in the core repo just so we can track the larger issue. I haven't dug into registration sources in a while, maybe there's no value for that flag anymore.

[tillig]

Looks like just setting that value to false on both registration sources fixes it. I chucked a PR in for that and can cut a bug fix release when it's through.

[tillig]

Published v6.0.1.