What does scoped lifetime for a service mean in Blazor (server)?

David Thielen 2,256

This is for Blazor (server).

According to this documentation, session scope for a service in Blazor (server side) means:

Scoped services aren't reconstructed when navigating among components on the client, where the communication to the server takes place over the SignalR connection of the user's circuit, not via HTTP requests.

And in this blog article (seems to be knowledgable):

It creates a scope for each so-called “circuit”. A circuit is created when a new browser tab connects to the Blazor server via the underlying SignalR transport, and it is terminated when the browser tab is closed again (or if the connection is lost and fails to reconnect within a specified time frame).

But in [this Microsoft Q&A](https://learn.microsoft.com/en-us/answers/questions/1276643/should-this-be-transient-scoped-(and-is-it-a-good) it says:

If this is a Blazor Server question then scoped behaves like a singleton. The official documentation covers how service life time works..

I think a singleton is the same object across all circuits/sessions. The documentation is as follows.

DI creates a single instance of the service. All components requiring a Singleton service receive the same instance of the service.

Of course "all components" can mean all components in a single circuit/session. Or it can mean all components across all circuits/sessions. I can see how if the "all components" is per circuit/session, then scoped is the same as singleton for most (all) use cases. But if singleton is a single instance across ever circuit/session, then they differ - a lot.

So what exactly is going on for scoped & singleton services on Blazor server?

thanks - dave

AgaveJoe 26,201 Reputation points

2023-05-07T17:10:03.8133333+00:00

A circuit is a persisted connection between client and the server. The scoped lifetime does not create a new service instance each time a the client navigates to a new component. Scoped has the same lifetime as circuit. It acts like a singleton as every component uses the same instance within the circuit.

A singleton is a single instance with same lifetime as the application. It is a globally shared instance - static.

There is nothing stopping you from creating a simple test to experiment a bit.
David Thielen 2,256 Reputation points

2023-05-08T06:09:14.3+00:00

I think there is a key difference - the singleton instance is shared by multiple circuits while the scoped instance is unique to each circuit. That's a giant difference.

Good explanation here.

While you're right that the lifetime of each for a given circuit is the same, that does not make them similar. Because they differ greatly in terms of sharing.
AgaveJoe 26,201 Reputation points

2023-05-10T12:44:11.6433333+00:00

I agree with your statement.

I feel the term singleton, which is a well-known design pattern, better describes a how a scoped registered service behaves from the perspective of the Blazor Server application loaded in the browser. This is especially important when the conversation leads to registering other design patterns with the DI container like unit-of-work, repository, etc.
David Thielen 2,256 Reputation points

2023-05-10T13:25:09.6633333+00:00

Keep in mind that always getting the same instance is only one attribute of the singleton pattern. There are other attributes of the singleton pattern including that the returned instance is shared by all code that requests it.

Accepted answer

VasimTamboli 4,410 Reputation points

2023-05-07T19:26:18.5966667+00:00

In Blazor Server, the lifetime of a scoped service is scoped to a single circuit. A circuit is created when a user connects to the server and is maintained for the duration of that user's session. When the user navigates between components within the same circuit, the same instance of the scoped service is used.

On the other hand, a singleton service is a single instance of the service that is shared across all circuits in the application. All components that require a singleton service receive the same instance of the service.

So, the statement from the Microsoft Q&A that "scoped behaves like a singleton" is not accurate. While it is true that a scoped service behaves like a singleton within a single circuit, it is not shared across all circuits in the application like a singleton service is.
Please sign in to rate this answer.
Bruce (SqlWork.com) 55,601 Reputation points

2023-05-10T17:02:24.9666667+00:00

this description of a blazor singleton service is not correct. a blazor singleton service is tied to the circuit. so every blazor app instance has its own singleton collection.

this is different than asp.net core DI, where all requests share the same singleton instance.
Sign in to comment

2 additional answers

Bruce (SqlWork.com) 55,601 Reputation points

2023-05-10T17:35:40.6633333+00:00

The answer is incorrect. Blazor singletons are not shared with all Blazer circuits. each Blazor circuit has its own singleton collection.

currently there is no functional difference between Singleton and Scoped in Blazor.
Please sign in to rate this answer.

1 person found this answer helpful.
David Thielen 2,256 Reputation points

2023-05-11T03:48:38.5933333+00:00

Please provide a link to Microsoft documentation that verifies this. Because I have not seen this anywhere. And if this is true, then it most definitely does not match the singleton pattern (which does not mean it is not true).

Granted, most of the documentation mentioning singleton could be read either way. But if the singleton truly operates this way, it must be documented somewhere.

Bruce (SqlWork.com) 55,601 Reputation points

2023-05-12T22:57:38.1033333+00:00

blazor apps have their own state and are designed as a client app. The singleton pattern still makes sense for client apps. You only need one object instance for the life of the application.

one has to careful with blazor as statics are still shared on server side blazor.

the HttpContext is an example of a an injected singleton. There is only one HttpContext for the life of the blazor app, so it makes sense to be a singleton.

note: under the covers DI just uses collections. In blazor the collection is in the blazor state.

Zachary Steudel 0 Reputation points

2023-07-20T16:38:42.2566667+00:00

By assigning GUIDs to an Scoped Service object, we were able to confirm they are shared between users, and if one user refreshes and another doesn't we can then see user B's token being used for user A. Have not solved the below.

Similarly, I was able to prove that a Scoped service is not behaving according to MS docs:

Created a Scoped service in Program.cs of my Blazor Server app

@inject it into the _Host.cshtml component in my app, set an attribute on it, write the attribute to the Console using the object's getter.

@inject it into a lower level component on a different page of the application and have it write the attribute to the console when the user navigates to that page

Navigate to the page(Not refreshing my browser, just navigating to a new component in the application), confirm that the attribute is empty when printed to the console

This indicates a Scoped service in Blazor Server is not behaving as the MS docs here suggest: https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/dependency-injection?view=aspnetcore-7.0#service-lifetime where it says "Scoped services aren't reconstructed when navigating among components on the client, where the communication to the server takes place over the SignalR connection of the user's circuit, not via HTTP requests."

David Thielen 2,256 Reputation points

2024-01-30T17:33:31.3433333+00:00

@Zachary Steudel And we still don't have an answer from Microsoft per your investigation & results. @Bruce (SqlWork.com) Could you get someone from the Blazor team to give us an accurate answer here? One that matches the actual results Zachary has shown? And if the documentation is incorrect, can you get them to fix it?

Zachary Steudel 0 Reputation points

2024-01-30T19:03:36.3+00:00

I think my above findings were partially incorrect. It seems that explicitly providing a getter/setter to the properties in my scoped class fixed the issue I was seeing and made it behave like the docs suggest. Here's a full explanation of the problem + my solution:

The original problem:

Create a class:

public class MyClass { public string? MyString; }

Add it as a scoped service in Program.cs

builder.Services.AddScoped<MyClass>();

Inject it into _Host.cshtml with @inject MyClass myClassInstance

Set myClassInstance.MyString = "Hi";

Inject MyClass into another component, print MyString to the console, observe that it's empty when you navigate to that page. This is the issue I outlined in my above comment.

Now the perplexing part is that I was able to fix this by simply adding a getter/setter on this property:

public class MyClass { public string? MyString { get; set; }; }

Now if you run the above exercise, the "Hi" string value should still exist in MyString when navigating to a different component. Now the scoped object behaves as the docs suggest.

Honestly this is probably just a misunderstanding on my part on how C# works (My background was mostly Java) but it seems that MyString was being re-initialized across components even if MyClass was scoped to my session. By adding an accessor/mutator to the property, C# treats it differently.

David Thielen 2,256 Reputation points

2024-01-30T20:19:46.16+00:00

@Zachary Steudel We still have @Bruce (SqlWork.com) claiming Scoped == Singleton though.
Sign in to comment
Sergey Ivanov 1 Reputation point

2024-01-29T23:45:35.58+00:00
What does Scoped mean in the case of WASM (WebAssembly)? I just created a new project from the FluentUI's template https://github.com/microsoft/fluentui-blazor and it added this line in my Program.cs

builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
Please sign in to rate this answer.
AgaveJoe 26,201 Reputation points

2024-01-30T14:09:06.95+00:00

According to the documentation, "Client-side doesn't currently have a concept of DI scopes. Scoped-registered services behave like Singleton services." https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/dependency-injection?view=aspnetcore-8.0

David Thielen 2,256 Reputation points

2024-01-30T17:30:40.15+00:00

The original question is about Blazor server side. To as about WASM please create a new ticket.
Sign in to comment