We're migrating an extensive webforms application to the .NET 5 /.NET Core world. We've moved much of the back end library code to .NET Standard 2.0.

As an interim step to incrementally move over functionality, we've set up an ASP.NET Core 2.2 (last version that runs on .NET Standard 2.0) project that runs within the .NET Framework webforms application. This works quite well except for one fatal flaw we've encountered: everything is the same scope, and so scoped objects are getting treated like singletons. Among other problems, this means the application latches onto the first logged-in user it sees. Transients are working correctly, though.

I'm using this library to properly route in the ASP.NET Core part of the app--without it everything comes back 404. But I'm not certain if the library is to blame or some other quirk of webforms.

Where should I look in the ASP.NET Core 2.2 pipeline for where each HTTP request is supposed to get its own IServiceProvider scope created to fix this or do it manually?

CodePudding user response：

The area I was looking for turns out to be the RequestServicesContainerMiddleware, which produces a new scope for each request. There's a check to see if an IServiceProvidersFeature is already set. The library I'm using defines this up front.

The solution/workaround for now is that I've added in a simplified version of the RequestServicesContainerMiddleware that always creates a new service scope.

(This unrelated answer on how to modify the DI system helped tremendously.)