-
Notifications
You must be signed in to change notification settings - Fork 310
HostEngine Start not setting HttpContext.ApplicationServices - uses default DI provider #337
Comments
Looks like a bug. |
@HaoK Can you investigate? |
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 |
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?
|
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. |
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 |
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 |
Fixed in 55b28ab |
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:
The text was updated successfully, but these errors were encountered: