-
Notifications
You must be signed in to change notification settings - Fork 311
Create a scoped service provider for the call to Configure #1106
Conversation
- This allows scoped dependencies to be injected into the Configure method. It means you can resolve the DbContext or any other scoped service without the hassle of the CreateScope boiler plate. As a side effect, it also makes Startup.Configure a bit more testable.
|
||
public class DisposableService : IDisposable | ||
{ | ||
public bool Disposed { get; set; } |
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.
Were you going to use this?
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.
Yea, but it's impossible to get to at the instance. I can remove 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.
Fixing 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.
🆙 📅
@pakrym one question I had, do we have a DI spec test that create "nested scopes". Scopes aren't nested in our container but will anything blow up if somebody was creating a scope on top of an existing scoped |
app.ApplicationServices = startup.ConfigureServicesDelegate(serviceCollection); | ||
startup.ConfigureDelegate(app); | ||
|
||
var instance = (StartupWithScopedServices)startup.StartupInstance; |
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.
You could've just registered factory and stored last created object.
Should we also have a DI spec test showing |
See aspnet/Hosting#1106 for details.
It means you can resolve the DbContext or any other scoped service without
the hassle of the CreateScope boiler plate. As a side effect, it also makes
Startup.Configure a bit more testable.
Inspired by issues like aspnet/Mvc#6407 and code like in our template that needs to create a scope in order to run db init logic.
One downside of this change. If you hold onto scoped services past the
Configure
method, they'll explode later. While this would have exploded by default in the new templates, it now works.