Open royvandertuuk opened 3 years ago
What you are seeing is the default service-scope-reuse behavior. For more information see this.
Thank you, this resolved the issue.
Why is the default behavior not ServiceScopeReuseBehavior.OnePerNestedScope
? As this is how ASP.NET Core DI is behaving by default? I read that it is to maintain the state of the request, but I assume you only lose request state when you explicitly start a new SimpleInjector scope within a request.
Why is the default behavior not ServiceScopeReuseBehavior.OnePerNestedScope? As this is how ASP.NET Core DI is behaving by default? I read that it is to maintain the state of the request, but I assume you only lose request state when you explicitly start a new SimpleInjector scope within a request.
That's correct. You'll only lose request state when you change the reuse behavior inside your manually created nested scope. As long as you don't create a nested scope within a request the OnPerRequest and OnePerNestedScope options behave identical.
OnPerRequest is the default behavior because "because it would otherwise force you to add quite some infrastructural code to get this data back". OnPerRequest is, therefore, the behavior that would works best for most developers, because most developers would expect their used framework components to still work, even if they create a nested scope.
Creating a
AsyncScopedLifestyle
scope inside of a ASP.NET Core web request does not result in a new scoped service when this service is resolved via Simple Injector ASP.NET Core cross wiring. Instead, it is resolving the same instance as in the other scope.I could only reproduce this issue in a ASP.NET Core app, I have attached a solution (Cross wiring issue.zip) that demonstrates the issue.
Below a snippet that produces the issue:
Resolve using cross wiring The
CoreScopedService
is registered in the ServiceCollection and cross wired using Simple Injector. Throws because scopedService1 and scopedService2 are the same instance.The same scenario is working in the following cases:
Defer resolving the instances until after the web request Does not throw, scopedService1 and scopedService 2 are separate instances.
Using SimpleInjector only Does not throw, scopedService1 and scopedService 2 are separate instances.
Using only ASP.NET Core DI Does not throw, scopedService1 and scopedService 2 are separate instances.