[6.4.0] same code different behavior in resolving service

DevOnBike commented 2 years ago

Describe the Bug

same code is running on .net 5 web app and .net 6 console app but it gives different behavior in runtime

Steps to Reproduce

public static void RegisterLogging(this ContainerBuilder builder)
        {
            // #1
            builder.Register(ctx =>
            {
                return new LoggerFactory().AddSerilog();
            }).As<ILoggerFactory>().SingleInstance();

            // #2
            builder.Register(ctx =>
            {
                var factory = ctx.Resolve<ILoggerFactory>();

                return factory.CreateLogger("Some.Logger");
            }).As<ILogger>().InstancePerLifetimeScope();
            builder.RegisterGeneric(typeof(Logger<>)).As(typeof(ILogger<>)).InstancePerLifetimeScope();
        }

Expected Behavior

on .net 5 both steps 1 and 2 are fired - if u place breakpoint it will stop in both places but under .net 6 code in section #1 is never fired!

Exception with Stack Trace

N/A

Dependency Versions

6.4.0

Additional Info

on request

tillig commented 2 years ago

In .NET 6 they changed how you build the hosting mechanism and how loving gets registered. It's all .NET hosting internals, not Autofac. Your net result is that the logger factory is likely created by the hosting system so it's never resolved from Autofac. If you look at Serilog integration, there's a hosting package that fixes it.

DevOnBike commented 2 years ago

In .NET 6 they changed how you build the hosting mechanism and how loving gets registered. It's all .NET hosting internals, not Autofac. Your net result is that the logger factory is likely created by the hosting system so it's never resolved from Autofac. If you look at Serilog integration, there's a hosting package that fixes it.

Maybe you didn't read carefully but my sample says that this wrong behavior is present in .net 6 console app where I don't have any host - it's pure use of autofac, nothing fancy so there some difference.

tillig commented 2 years ago

I guess my point is, if there is a difference, it's not Autofac. And the reasoning is still the same - web apps have extra stuff going on in logging wire-up that don't happen in straight console apps. All of that is .NET internals, not Autofac. Web apps will use a Startup class and hosting, straight console apps won't. I mean, you're literally saying, "I have two totally different app types that have two totally different mechanisms of wiring up logging and two totally different hosting models running across two different major versions of .NET and they don't behave identically." That's not Autofac. If it was the same app type, same code, same everything, but .NET upgrade, that might be Autofac. Maybe. But Autofac uses the hooks provided by the framework and the code you write. If the ILoggingFactory you register isn't getting hit, it's because

Something else in your app somewhere is registering a different ILoggingFactory implementation that is overriding your registration. That may be the hosting framework, that may be services.UseLogging(), it may be something else. OR
Nothing is actually resolving the ILoggingFactory in the app where you think it should.

Either way, this is a .NET framework problem to troubleshoot or something in your app code, but not Autofac.

autofac / Autofac