aspnet / Hosting

[Archived] Code for hosting and starting up an ASP.NET Core application. Project moved to https://github.com/aspnet/Extensions and https://github.com/aspnet/AspNetCore
Apache License 2.0
552 stars 312 forks source link

HostEngine Start not setting HttpContext.ApplicationServices - uses default DI provider #337

Closed ghost closed 9 years ago

ghost commented 9 years ago

I am returning a UnityServiceProvider from ConfigureServices and I can see that it is being set to the ApplicationServices property (above the HostingEngine.Start method in top right of image below), however the httpContext.ApplicationServices is null which causes it to use _services resulting in the default DI provider to be used. I see the DefaultControllerActivator retrieves the HttpContext.RequestServices (default provider) resulting in my HomeController not resolving IFoo as expected (line 104 left pane) since it is not using my UnityServiceProvider.

I am making assumptions based on the limited documentation available during internet research, but will be glad to blog the topic if I am missing something and you can elaborate...

UPDATED: My work around was to add the following line in HostEngine.Start() that sets RequestServices as follows:

                using (logger.BeginScope("Request Id: {RequestId}", requestIdentifier))
                {
                    // BillKrat.2015.08.23 - work around so DI container is used
                    httpContext.RequestServices = ApplicationServices;

                    contextAccessor.HttpContext = httpContext;
                    await application(httpContext);
                }

serviceprovider

davidfowl commented 9 years ago

Looks like a bug.

glennc commented 9 years ago

@HaoK Can you investigate?

HaoK commented 9 years ago

Ah, this is probably a sideeffect of 'cleaning up' some of the weird logic last time... Yeah I'll take a look and add a test for this

HaoK commented 9 years ago

So I added a test which is just verifying that ApplicationServices is set to the IServiceProvider returned via ConfigureServices (shown below), which works fine. Are you not seeing context.ApplicationServices being set to the one returned from your ConfigureServices method?

        public class CustomContainerStartup
        {
            public IServiceProvider Services;
            public IServiceProvider ConfigureServices(IServiceCollection services)
            {
                Services = services.BuildServiceProvider();
                return Services;
            }

            public void Configure(IApplicationBuilder app)
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("ApplicationServicesEqual:" + (context.ApplicationServices == Services));
                });
            }
        }
ghost commented 9 years ago

Actually this was observed during HostingEngine.Start. In the following excerpt from the image above you'll see that at my breakpoint the ApplicationServices property is properly set to my UnityServiceProvider. However, execution of line 79 has the middleware setting httpContext.RequestServices to (default) ServiceProvider (line 43) because httpContext.ApplicationServices was null so it used the _services value which is highlighted in yellow box of the bottom pane below.

Perhaps this was a beta 6 issue? I'll upgrade to latest and see if the problem persist, may take a wee bit because of my wife's honey-do list (which entails lawn mowers, edging, and weed eating) and I'm still new with attaching to source code (I'm old school Microsoft crony and TFS is my comfort zone) but I should know in a couple of days.

middleware

HaoK commented 9 years ago

Ah okay yeah we tweaked this code a bit recently, so hopefully this was fixed already as part of that. let me know if you still see issues once you've upgraded

HaoK commented 9 years ago

Ah okay I think I see the issue, we aren't explicitly setting the ApplicationServices on the context it looks like, so maybe there's a gap somewhere

HaoK commented 9 years ago

Fixed in 55b28abeab524c39bacc1a0e0717d5126ec3a6a7