Skip to content

Disposing disposable transient services in Blazor #54376

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 task done
AntMaster7 opened this issue Mar 5, 2024 · 2 comments
Closed
1 task done

Disposing disposable transient services in Blazor #54376

AntMaster7 opened this issue Mar 5, 2024 · 2 comments
Labels
area-blazor Includes: Blazor, Razor Components ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. Status: Resolved

Comments

@AntMaster7
Copy link

AntMaster7 commented Mar 5, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Someone opened this same issue some years ago. However, it was closed and the answer given in that issue appears to be wrong.

In the section Disposal of services in the ASP.NET Core documentation it states: "The container calls Dispose for the IDisposable types it creates. Services resolved from the container should never be disposed by the developer.".

However, this appears to be not the case with Blazor. Whereas the Dispose method of components is called if they implement the IDisposable interface, the injected services (given they are transient) are not disposed. I do believe one of the reasons for a DI container is lifetime management. A component should not be aware of the lifetime of a service it consumes.

Describe the solution you'd like

Injected transient services get disposed once a component gets disposed.

Additional context

I'm not sure if this might even be considered a bug because it contradicts the documentation.

@ghost ghost added the area-blazor Includes: Blazor, Razor Components label Mar 5, 2024
@SteveSandersonMS
Copy link
Member

In the section Disposal of services in the ASP.NET Core documentation it states: "The container calls Dispose for the IDisposable types it creates. Services resolved from the container should never be disposed by the developer.".

In Blazor the DI container does dispose transient services at the end of the lifetime of the DI container (e.g., the end of a Blazor Server circuit). It can't dispose them any earlier because there's nothing to define a shorter lifetime. As such, the doc is correct (and the comment you linked to is incorrect, since the DI container does track even transient instances).

This isn't very useful, because of course you probably do want them to be disposed earlier. Unfortunately this is a design limitation with DI that applies to all long-lived app contexts (Blazor Server, Console apps, WinForms, etc.).

We have an issue tracking the desire to improve how the DI container works to handle these long-lived app scope scenarios: #26676.

Mainly, for now, we recommend not using transient services in long-lived DI scopes such as Blazor Server circuits. Or if you must do, then create and dispose your own DI scope for a shorter unit of work, or use the OwningComponentBase base class to simplify this pattern.

@SteveSandersonMS SteveSandersonMS closed this as not planned Won't fix, can't repro, duplicate, stale Mar 5, 2024
@SteveSandersonMS SteveSandersonMS added the ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. label Mar 5, 2024
@AntMaster7
Copy link
Author

Thank you so much @SteveSandersonMS for taking the time to look into this. I have no idea how you guys are able to manage so many requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. Status: Resolved
Projects
None yet
Development

No branches or pull requests

2 participants