.NET › Blazor (Server & WebAssembly)

How does service lifetime (Scoped, Singleton, Transient) have different practical meaning in Blazor Server versus Blazor WebAssembly?

Advanced

Answer

In Blazor Server, a 'Scoped' service lifetime maps to one circuit (one user's session), so a scoped service is effectively per-user, similar to per-HTTP-request scoping in typical ASP.NET Core but lasting the whole connected session. In Blazor WebAssembly, since the entire app runs in one browser tab as a single client-side process, Scoped and Singleton are effectively equivalent -- there's only ever one 'scope' for the whole WASM app instance, since there's no server-side per-request/per-circuit boundary.

// Blazor Server: Scoped = per-user circuit
builder.Services.AddScoped<ShoppingCartState>();  // isolated per connected user

// Blazor WebAssembly: Scoped behaves like Singleton (one process per tab)
builder.Services.AddScoped<ShoppingCartState>();  // effectively one instance for the whole app

Real-world example A shopping cart state service registered as Scoped correctly isolates each user's cart in Blazor Server (one instance per circuit) but would behave identically to a Singleton if the same app were instead deployed as Blazor WebAssembly.

Common follow-ups: What happens if you mistakenly register a service as Singleton in Blazor Server expecting per-user isolation?;How does this affect testing services across both hosting models?

Dependency Injection;Caching (In-Memory Distributed & Redis)