OpenGenericServiceBinder.TryBindOpenGenericTypedService behavior does not match assignability rules for uncommon edgecase

[PTwr]

Describe the Bug

Upon further debugging, OpenGenericServiceBinder.TryBindOpenGenericTypedService returns false where Type.IsAssignableFrom returns true for edgecase where generic parameters are not passed through to interfaces:

For example:

class InsaneUsecase<TParam> : IWhatever<int> {}

Is assignable to IWhatever<int> but Autofac consider this not a match.

When interfaces deemed by Autofac to be incompatible are inherited (thus placed first on list, which can be simulated manually as described below), it causes weird issues possibly relating to #1465 but the core issue is independent.

---

Nested open generics cause order of interfaces to matter when resolving enumeration.

Issue can creep out through base classes, as inherited interfaces are earlier when enumerating interfaces.

There's probably some silly oversight when checking interfaces of Type somewhere in depths of Autofac.

Steps to Reproduce

using Autofac;

namespace xunit_tests
{
    public class UnitTest1
    {
        [Fact]
        public void WeirdBug()
        {
            ContainerBuilder builder = new ContainerBuilder();

            builder
                .RegisterGeneric(typeof(Handler_x_then_base<>))
                .As(typeof(IHandler<>).MakeGenericType(typeof(IRequest<>)));
            builder
                .RegisterGeneric(typeof(Handler_base_then_x<>))
                .As(typeof(IHandler<>).MakeGenericType(typeof(IRequest<>)));

            var container = builder.Build();

            var handlers = container
                .Resolve<IEnumerable<IHandler<IRequest<int>>>>();

            // both handlers should be resolved, but only one is
            Assert.Equal(2, handlers.Count());
        }

        public interface IHandler<in T> { }
        public interface IRequest { }
        public interface IRequest<T> { }

        // working 
        public class Handler_x_then_base<TParam>
        : IHandler<IRequest<TParam>>, IHandler<IRequest>
        { }
        // not working, same as if IHandler<IRequest> were to be inherited via base class
        public class Handler_base_then_x<TParam>
        : IHandler<IRequest>, IHandler<IRequest<TParam>>
        { }

        // overcomplicated usecase that works because there is one less generic level
        [Fact]
        public void SimplerCaseWorks()
        {
            ContainerBuilder builder = new ContainerBuilder();

            builder
                .RegisterGeneric(typeof(Thing<>))
                .As(typeof(IThing<>));
            builder
                .RegisterGeneric(typeof(Stuff<,>))
                .As(typeof(IThing<>.IStuff<>));
            builder
                .RegisterGeneric(typeof(ThingStuffA<,>))
                .As(typeof(IThing<>.IStuff<>));
            builder
                .RegisterGeneric(typeof(ThingStuffB<,>))
                .As(typeof(IThing<>.IStuff<>));
            builder
                .RegisterGeneric(typeof(ThingStuffC<,>))
                .As(typeof(IThing<>.IStuff<>));

            var container = builder.Build();

            var things = container.Resolve<IEnumerable<IThing<int>>>();
            var stuff = container.Resolve<IEnumerable<IThing<int>.IStuff<string>>>();

            Assert.Equal(1, things.Count());
            Assert.Equal(4, stuff.Count());
        }

        public interface IThing<TThing>
        {
            public interface IStuff<TStuff> { }
        }

        public class Thing<T> : IThing<T> { }
        public class Stuff<TThing, TStuff> : IThing<TThing>.IStuff<TStuff> { }
        public class ThingStuffA<TThing, TStuff> : IThing<TThing>, IThing<TThing>.IStuff<TStuff> { }
        public class ThingStuffB<TThing, TStuff> : IThing<TThing>.IStuff<TStuff>, IThing<TThing> { }
        public class ThingStuffC<TThing, TStuff> : Thing<TThing>, IThing<TThing>.IStuff<TStuff> { }
    }
}

Expected Behavior

Order of interfaces should not matter

Exception with Stack Trace

No exception

Dependency Versions

Autofac: 8.3.0
Issue was found on 7.1.0 in .NET 4.8, reproduced in 8.3.0 in .NET 4.8 and in .NET 8

[tillig]

Yow, interesting stuff.

We'd love to see a PR to help resolve this. Nested types can kind of get tricky since it's not types within a namespace, so your theory that there's something odd reflection-wise when it comes to this is probably spot-on.

That said, I can't promise folks will "jump right on this" since it's a bit of an edge case and there are even built-in framework analyzers that guide people away from publicly-visible nested types. If you want a fast fix, your best bet is to submit a PR.

[PTwr]

Yow, interesting stuff.

We'd love to see a PR to help resolve this. Nested types can kind of get tricky since it's not types within a namespace, so your theory that there's something odd reflection-wise when it comes to this is probably spot-on.

That said, I can't promise folks will "jump right on this" since it's a bit of an edge case and there are even built-in framework analyzers that guide people away from publicly-visible nested types. If you want a fast fix, your best bet is to submit a PR.

Ye, I discovered it on a nested factory'ish classes with optional features as it makes juggling bunch of generics much fancier. Might be a case of severe "I did it because I could". And you can't do typeof(IFoo<IBar<>>) but typeof(IFoo<>.IBar<>) works :)

Got a workaround for now, composition instead of inheritance, but just distilling exact issue took its tool on my mental fortitude so I'll return to this issue in later time. Got another nuget package to make PR for first, digging through decades of tech debt always uncovers fun edge cases...

The issue itself, as distilled in attached test case, can happen with no inheritance dark arts. All that's needed is questionable design choices resulting in generic handler for generic events, with one handler handling multiple event types. Second test case was just to confirm that the issue occurs only for overly-nested generics, but not for typical usecase.

Now that I had a time to think about my discoveries, there is even simpler test case. which my ThingStuff test simply failed to reproduce.

builder
    .RegisterGeneric(typeof(GenericMismatchWithInterface<>))
    .As(typeof(IHandler<>));

...

public class GenericMismatchWithInterface<TParam>
    : IHandler<int> //  <-- not TParam from class signature
{

}

Resolving for IEnumerable<IHandler<int>> does not return this abomination, despite it being assignable to requested type.

So it seems its boils down to erroneous behavior when class signature is not applicable to its generic interface. Given that this example is not something that should survive code review I would not be surprised if there is a decade old assumption in Autofac code that class interface will match its open generic registration. I'd bet a potato that its same piece of code that nicely handles open generics with constraints.