Rendering a component: An injected scopeded instance differs from the one from RequestServices

[TPIvan]

Describe the bug

When I configure a service for being injected with scoped lifetime (.AddScoped), the instance which is injected to a component field is different from the instance which can be obtained by calling HttpContext.RequestServices.GetService. The problem occurs in blazor-server (services.AddServerSideBlazor();) when rendering a component (render-mode="Server" or second pass when render-mode="ServerPrerendered"). When the component is prerendered (render-mode="Static" or first pass when render-mode="ServerPrerendered") the instaces are the same (as expected).

To Reproduce

1. Create a new Blazor App / Blazor Server App project

2. Create a new Class

     public class MyTesingClass {}
   

3. Configure DI for HTTP context and the created class

     services.AddHttpContextAccessor(); 
     services.AddScoped<MyTesingClass>(); 
   

4. Put the following code to Index.razor

    @inject Microsoft.AspNetCore.Http.IHttpContextAccessor contextAccessor
    @inject MyTesingClass  myInstance;
    <div>
      Instances are the same: @(myInstance == contextAccessor.HttpContext.RequestServices.GetService(typeof(MyTesingClass)))
    </div>
   

5. Run the project - the result is false

6. Change render-mode="ServerPrerendered" in (_Host.cshtml) to render-mode="Static"
   The result is true

There is also SO question: Blazor: HttpContext.RequestServices provides a different scoped instance than IServiceProvider

Further technical details

• ASP.NET Core version

.NET Core SDK (reflecting any global.json):
Version: 3.1.101
Commit: b377529961

Runtime Environment:
OS Name: Windows
OS Version: 10.0.18362
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.1.101\

Host (useful for support):
Version: 3.1.1
Commit: a1388f194c

.NET Core SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.509 [C:\Program Files\dotnet\sdk]
2.2.103 [C:\Program Files\dotnet\sdk]
3.1.101 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
BlazorApp11.zip

• The IDE VS 2019 16.4.5

[javiercn]

@TPIvan thanks for contacting us.

That's by design. Circuits create their own scope when they are initialized and that scope is not shared with the request scope.

[TPIvan]

Is that mentioned somewhere in documentation? If not it should be because it is at least a bit surprising.

Is there a singleton service which allows to obtain instances in the circuit scope? The scenario is a need to obtain scoped instance in a singleton class (like in Using Scoped dependencies in Singletons in ASP.NET Core). The instance obtained through IServiceProvider didn't seem to be right one.

[javiercn]

I'm not sure about the details on that article you reference, but in general trying to get a scoped instance within a singleton is wrong.

I'm not sure what you are trying to accomplish, if you provide more details maybe we can help.

[TPIvan]

I am in early stage of planning a step by step migration strategy for a webforms project. The webforms application uses a session singleton (session variable encapsulated in static property), which is accessed from a custom validation attribute. So I was looking for an equivalent of this a static encapsulation for data dependent on request content.
So I have a static property in a standard library to which I need to assign a singleton instance having access to a scoped instance.
By the mentioned article and my experiment the task can be completed with a class holding HTTPContextAccessor providing the needed scoped instance (via HttpContext.RequestServices.GetService).
The problem is that this instance is different that the one standardly injected. So one has to be carefull not to use standard injection.
To access instances I am using the following class

    public class ScopedDataAccessor : IScopedDataAccessor
    {
        private IHttpContextAccessor contextAccessor;
        //Using Scoped dependencies in Singletons in ASP.NET Core http://morgwai.pl/articles/aspdi.html
        //It is necessary to use this way always(mixing creates multiple instances!) 
        public ScopedDataAccessor(IHttpContextAccessor contextAccessor)
        {
            this.contextAccessor = contextAccessor ?? throw new ArgumentNullException(nameof(contextAccessor));
        }
    
        public T GetValue<T>()
        {
            return contextAccessor.HttpContext.RequestServices.GetRequiredService<T>();
        }
    }

[javiercn]

@TPIvan accessing the HttpContext in server-side blazor applications is wrong, since "circuits" are not attached to a specific httpcontext.

I think you should be able to achieve what you want (per-scope "static" data) using an AsyncLocal field instead of a static. If you have anything that is tied to the session and don't need to access it statically, the recommendation is to declare a scoped service and inject it.

If you need to access it from a static variable, I think you can make it work with an async local, and performing initialization within a circuit handler.

/cc @pranavkm in case he has more ideas.

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.