[API Proposal]: Scoped Service Provider Accessor

[Waleed-KH]

Background and motivation

In modern .NET applications, developers heavily rely on dependency injection (DI) scopes to manage the lifetime of resources per operation (e.g., handling a web request, processing a message queue item, or executing a background task). While ASP.NET Core provides IHttpContextAccessor to access the current HTTP context and its associated RequestServices ambiently, .NET lacks a generic, runtime-agnostic mechanism to access the active IServiceProvider scope outside of web environments.

This limitation frequently causes architectural pain points in non-web applications (such as Worker Services, Console Apps, or any Generic Host), or when writing infrastructure libraries that span both web and non-web contexts. For example:

• Cross-Lifetime Consumption: A Singleton service needs to process contextual data or interact with a stateful Scoped service, but it is invoked from deep within a scoped execution pipeline where passing IServiceProvider explicitly through method signatures is impossible or highly intrusive.
• Library Authoring: Infrastructure components need to ambiently fetch services from the active scope without forcing application code to manually flow the container down the call stack.

Providing a built-in IScopedServiceProviderAccessor powered by AsyncLocal<T> resolves these issues. It standardizes ambient scope tracking natively within Microsoft.Extensions.DependencyInjection, bringing parity to non-web hosting environments and eliminating the need for developers to repeatedly implement custom, error-prone thread-local or async-local tracking wrappers.

API Proposal

namespace Microsoft.Extensions.DependencyInjection;

/// <summary>
/// Provides access to the current scope <see cref="IServiceProvider"/>, if one is available.
/// </summary>
public interface IScopedServiceProviderAccessor
{
    /// <summary>
    /// Gets or sets the current scope <see cref="System.IServiceProvider"/>. Returns <see langword="null" /> if there is no active scope.
    /// </summary>
    IServiceProvider? ServiceProvider { get; set; }
}

API Usage

public class SingletonService(IScopedServiceProviderAccessor scopeAccessor)
{
    private readonly IScopedServiceProviderAccessor _scopeAccessor = scopeAccessor;

    public void DoSomething()
    {
        // Effortlessly retrieve the caller's scoped provider instance
        var scopedProvider = _scopeAccessor.ServiceProvider;

        if (scopedProvider is not null)
        {
            // Resolve scoped service specific to this call execution flow
            var currentUser = scopedProvider.GetRequiredService<UserContext>();
        }
    }
}

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-dependencyinjection
See info in area-owners.md if you want to be subscribed.

[svick]

As I understand it, DI currently does not have the concept of an "active scope". Are you saying that whenever a scope is created, it should be set as the active scope, and preserved using AsyncLocal<T>, so that it can be accessed from IScopedServiceProviderAccessor?

I'm not sure that's reasonable for all the apps that don't need this feature.

[Waleed-KH]

That is a very fair point. To address the performance concern, the container may not track scopes by default. Instead, the tracking should be completely opt-in. It would only activate if a user explicitly calls services.AddScopedServiceProviderAccessor() during startup.

When registered, the accessor would act as a lightweight piece of infrastructure—similar to how IHttpContextAccessor is completely opt-in and idle in ASP.NET Core unless explicitly added. This guarantees zero overhead and zero performance impact for apps that do not need the feature.

[Clockwork-Muse]

Noting that this is a form of the Service Locator pattern, which is often considered an anti-pattern.

Both of the potential use cases you've listed make me feel like some form of wider architectural changes are warranted in applications that want something like this.

[ScarletKuro]

AsyncLocal can sometimes bite you pretty hard, since not everything flows through the ExecutionContext:
#47802
reactiveui/ReactiveUI#3258 (comment)

There are more cases, but this is the one I remember best. Because of this, I prefer to avoid ambient scoping in DI.

[rosebyte]

You're right that this feels like a gap for non-web applications that need a similar thread-per-unit-of-work flow. The main problem I see is that we own the request execution model in ASP.NET Core. A general application, however, can use any threading model, so fitting a scope creation and disposal mechanism into that would be quite tricky, and we would likely introduce a solid number of landmines by trying.

Besides, we pay a cost for every AsyncLocal in terms of performance, so it makes more sense to pay it once and have a complete AsyncLocal-based context that can be reused, rather than storing only the bare IServiceProvider.

Anyway, there's nothing preventing anyone from creating an AsyncLocal and providing some shared code that encapsulates the technical details, so we could build a nice third-party package that services can use if it fits their needs.

[Waleed-KH]

Thank you for the thoughtful feedback. You raise incredibly valid points regarding execution control and contexts. However, I want to clarify why having this built-in is fundamentally superior to third-party packages:

A general application, however, can use any threading model, so fitting a scope creation and disposal mechanism into that would be quite tricky, and we would likely introduce a solid number of landmines by trying.

You rightly noted that a general application can use any threading model. However, most general applications strictly follow standard .NET asynchronous flows, which AsyncLocal handles perfectly under the hood. If an application uses a highly exotic, custom threading model that breaks async context propagation, then they should be aware that the default AsyncLocal-based accessor may result in unexpected behavior.

Besides, we pay a cost for every AsyncLocal in terms of performance, so it makes more sense to pay it once and have a complete AsyncLocal-based context that can be reused, rather than storing only the bare IServiceProvider.

That's an excellent point. This proposal could serve as the foundational starting point for a broader, first-class scope context in non-web apps. e.g.:

public interface IServiceScopeContext
{
    IServiceProvider ServiceProvider { get; }
    IServiceFeatureCollection Features { get; }
}

public interface IServiceFeatureCollection
{
    TFeature? Get<TFeature>();
    void Set<TFeature>(TFeature? instance);
}

Anyway, there's nothing preventing anyone from creating an AsyncLocal and providing some shared code that encapsulates the technical details, so we could build a nice third-party package that services can use if it fits their needs.

Leaving this to third-party packages forces every worker service, event loop, or consumer framework to manually wrap CreateScope(), or decorate IServiceScopeFactory to set and clear an external tracker. Natively baking this eliminates this friction entirely, and establishes a universal standard way to access the ambient scope. Also infrastructure library authors desperately need a single, built-in 'source of truth' or at least standardized way to ambiently access scoped services without forcing end-user apps to use custom DI third-party package.

By building it into Microsoft.Extensions.DependencyInjection, the container can handle this seamlessly under the hood. When AddScopedServiceProviderAccessor() is called, the internal CreateScope() and Dispose lifecycle can automatically flow the current scope instance into the accessor. Libraries can simply inject IScopedServiceProviderAccessor and trust that the runtime has already mapped the active scope flawlessly.