[Blazor] Scoped service multiple initializations in client side blazor

[stavroskasidis]

Describe the bug

Consider the following scenario in a blazor client-side app:

public class ScopedService
{
    public ScopedService()
    {
        Console.WriteLine("Scoped Service created");
    }
}

public class AppState
{
    private readonly ScopedService scopedService;

    public AppState(ScopedService scopedService)
    {
        this.scopedService = scopedService;
    }
}

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<AppState>();
        services.AddScoped<ScopedService>();
    }
    //...
}

MyComponent.cshtml

@inject AppState state
<h1>Component that injects AppState and contains ComponentThatUsesScopedService</h1>
<ComponentThatUsesScopedService />

ComponentThatUsesScopedService.cshtml

@inject ScopedService service
<h1>ComponentWithScopedService</h1>

Expected behavior

According to documentation

Client-side Blazor doesn't currently have the concept of DI scopes. Scoped behaves like 
Singleton. However, ASP.NET Core Razor Components support the Scoped lifetime. In a Razor 
Component, a scoped service registration is scoped to the connection. For this reason, using 
scoped services is preferred for services that should be scoped to the current user, even if 
the current intent is to run client-side in the browser.

The ScopedService class should behave like a singleton and be created only once.

Actual behavior

The ScopedService class is created more than once:

WASM: Scoped Service created
WASM: Scoped Service created

Is this behaviour intended ? If so then this is a problem for library authors that want to support both Blazor client-side and server-side and need to register services "per-connection" in the DI.

If the consumer of your library in a blazor client-side app uses singleton registration and depends on your scoped service, then this may lead to wierd bugs.

[javiercn]

You are passing a scoped service to a singleton instance, that is the root of the issue. If all services are declared scoped you should be fine. Your singleton service should be registered as scoped, what the text in the docs is saying is that you don't need to register them as singleton, that you can register them as scoped and there will not be any difference.

@SteveSandersonMS We could potentially enable this so as to cause an exception to be thrown at startup time. https://github.com/aspnet/Extensions/blob/master/src/DependencyInjection/DI/src/ServiceCollectionContainerBuilderExtensions.cs#L33

I don't think there's anything we can do about it.

[SteveSandersonMS]

@javiercn Yes, validateScopes sounds good. I agree it would be best to throw given a non-meaningful DI config.

[stavroskasidis]

I agree that it is a misconfiguration. The example senario I have described would throw in a server-side context. It should do the same for client-side at least.

May I even suggest that the AddSingleton API is somehow "removed" from the client-side service collection, since it provides no value and may confuse consumers ?

[SteveSandersonMS]

Singletons have valid use cases (e.g. globals). They just can’t take scoped services as dependencies.

[stavroskasidis]

Ok, I see what you mean now. You are right, I was thinking of singletons only in the context of client-side blazor, but I forgot that you may want to register services in a library that are both singleton and scoped, so that it works correctly on both server-side and client-side hosting models 👍