8000 Imprecise note wording regarding the use of scoped services? · Issue #45617 · dotnet/docs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Imprecise note wording regarding the use of scoped services? #45617

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
fterrani opened this issue Apr 3, 2025 · 3 comments · Fixed by #46459
Closed

Imprecise note wording regarding the use of scoped services? #45617

fterrani opened this issue Apr 3, 2025 · 3 comments · Fixed by #46459
Assignees
Labels
dotnet-fundamentals/svc 📌 seQUESTered Identifies that an issue has been imported into Quest.

Comments

@fterrani
Copy link
fterrani commented Apr 3, 2025

Type of issue

Missing information

Description

The note in the Scoped section seems imprecise to me:

Do not resolve a scoped service from a singleton and be careful not to do so indirectly, for example, through a transient service. It may cause the service to have incorrect state when processing subsequent requests. It's fine to:

  • Resolve a singleton service from a scoped or transient service.
  • Resolve a scoped service from another scoped or transient service.

When reading this, one could think using a scoped service from a singleton service is absolutely forbidden in any scenario. However, this looks contradictory with what's shown there in those pages/section regarding IServiceScopeFactory:

Maybe my wording is incorrect, but to me, a scoped service is indeed resolved and ends up being injected in a singleton service in these situations. It's just that it is not done badly via constructor or IServiceProvider but cleanly from within a scope created with IServiceScopeFactory.CreateScope() in the singleton service. I think the meaning of resolving a scoped service from a singleton isn't clear enough and that the following introduction could be used to make the message clearer:

A scoped service should always be used from within a scope, either implicit like ASP.NET Core's per-request scope or explicit by creating one with IServiceScopeFactory.CreateScope().
Do not resolve a scoped service directly (via constructor dependency injection or via IServiceProvider) from a singleton [...]

In other words, while conforming to the current version of the note is a sufficient condition, using a scope seem to be a necessary and sufficient condition that is worth mentioning.

Page URL

https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection#scoped

Content source URL

https://github.com/dotnet/docs/blob/main/docs/core/extensions/dependency-injection.md

Document Version Independent Id

cc5f00d0-fb50-1229-8fa2-e66b1f45b284

Platform Id

7f5b5732-fc3e-6ffb-b8b8-77b5659a8015

Article author

@IEvangelist

Metadata

  • ID: 8fd55089-b683-2202-6641-c7b61a132f14
  • PlatformId: 7f5b5732-fc3e-6ffb-b8b8-77b5659a8015
  • Service: dotnet-fundamentals

Related Issues


Associated WorkItem - 417526

@IEvangelist
Copy link
Member

Yeah, this can be a bit confusing and hard to articulate. Thanks for posting this issue @fterrani, would you be interested in proposing a PR to address this? The main idea is that if you have a Singleton or Transient service, and you try requiring a service that's registered as Scoped in the .ctor, it will throw at runtime. You're required to use the IServiceScopeFactory to create a scope and then resolve the service within said scope.

@IEvangelist IEvangelist added 🗺️ reQUEST Triggers an issue to be imported into Quest. and removed ⌚ Not Triaged Not triaged labels Apr 3, 2025
@dotnetrepoman dotnetrepoman bot added the 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. label Apr 3, 2025
@dotnet-policy-service dotnet-policy-service bot removed the 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. label Apr 3, 2025
@sequestor sequestor bot added 📌 seQUESTered Identifies that an issue has been imported into Quest. and removed 🗺️ reQUEST Triggers an issue to be imported into Quest. labels Apr 4, 2025
@fterrani
Copy link
Author
fterrani commented Apr 6, 2025

@IEvangelist I can try, but I cannot guarantee anything since my understanding of that topic isn't deep enough and I'm not sure I'll find the time. I'll get back to you here and/or via a PR if I manage to come up with something.

@cmastr cmastr moved this from 🔖 Ready to Slipped in dotnet/docs April 2025 sprint project May 20, 2025
@dotnetrepoman dotnetrepoman bot added the 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. label May 20, 2025
@dotnet-policy-service dotnet-policy-service bot removed the 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. label May 20, 2025
@IEvangelist IEvangelist moved this from 🔖 Ready to 🏗 In progress in dotnet/docs May 2025 sprint project May 27, 2025
@dotnetrepoman dotnetrepoman bot added the 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. label May 27, 2025
@dotnet-policy-service dotnet-policy-service bot removed the 🗺️ mapQUEST Only used as a way to mark an issue as updated for quest. RepoMan should instantly remove it. label May 27, 2025
IEvangelist added a commit to IEvangelist/docs that referenced this issue May 28, 2025
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in dotnet/docs May 2025 sprint project May 28, 2025
@fterrani
Copy link
Author

@IEvangelist Thanks for the fix 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dotnet-fundamentals/svc 📌 seQUESTered Identifies that an issue has been imported into Quest.
Projects
Status: ✅ Done
Development

Successfully merging a pull request may close this issue.

2 participants
0