Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed MVC dependency injection. #3520
Fixed MVC dependency injection. #3520
Changes from all commits
c0b727b
72ede51
3bf179d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Controllers were explicitly removed from the Container because of memory leak problems. In earlier versions of Dependency Injection the controllers that got registered in the container would never be collected by the Garbage Collector. This means if you have 100,000 requests to a specific controller, you would have 100,000 instances of the controller in memory.
I am hesitant to add controllers back in unless there is a very good reason for it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #3520 (comment) for the reasoning behind the memory leak.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perfect, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to re-do the same testing that was done to validate the fix that was put in place in 9.4.x to ensure that we don't have a leak, but this looks to be the better way regardless
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please note that if the controllers are not registered in the container it will not be able to resolve them. Which means that in 9.4.4 (apart from the provider being always null) the controllers were always resolved from the asp net DefaultControllerFactory
_resolver
that was passed in, which only supports parameterless constructors, so no DI for them.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean you got Dependency Injection working in HTTP Modules or is this needed to access the System.Web Scope?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This HttpModule is the one that handles the entire request scope lifetime. It handles it for all module types (WebForms, MVC, WebApi). For WebForms we need to look at what is injected in the DependecyProvider property of PortalModuleBase. It should be the request scope provider and not the root one.
As stated in the TODOs, this should be the first HttpModule in the pipeline for BeginRequest so that the scope is opened as soon as possible in the request lifetime (all HttpModules after it can access the opened scope through the instance stored in HttpContext.Items - they will not have constructor DI though). The same HttpModule should be the last that executes it's EndRequest so that the scope is disposed as late as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, thanks for the explanation on what is going on with this code. It helps me a lot and I'm sure it will help others that review this change later.
This sounds like the correct way and I would argue the way I should have implemented this in the first place. I'm actually fine keeping this as an attribute on the class. Something like this shouldn't be configured in the web.config, creates another point of failure on a part of the platform that isn't designed to be plug and play