DEV Community: Anton

.NET: how to consume a scoped service from a singleton?

Anton — Fri, 09 Oct 2026 07:48:25 +0000

This is a short post about a very specific C#/.NET topic. They say one needs to pick their battles. Here I decided to pick a battle with a StackOverflow answer from 2018 and a couple of fellow tech bloggers, because I have opinions. This is not exactly a tutorial, so I assume the reader has some basic understanding of .NET, its DI mechanisms and service lifetimes.

Q: In .NET, how to consume a scoped service from a singleton?

A: Just google it.

One of the first search results is a StackOverflow question. It has an accepted answer with 270+ upvotes. The answer solves the original poster's problem and is technically correct, thus having the worst type of correctness. To nobody's surprise, it's also the answer LLMs regurgitate if asked.

I believe the answer is wrong and detrimental for application architecture. I'm generally done with SO, and SO itself is in its death throes, so instead of fighting over an answer from 2018 on a dead website I'll write about it here.

The Problem

So our .NET app has two services. One is scoped and another one is singleton, and the former can't be directly consumed from the latter:

// Program.cs
builder.Service.AddSingleton<IMySingleton, MySingleton>();
builder.Service.AddScoped<IMyScoped, MyScoped>();

// elsewhere
class MySingleton: IMySingleton {
    private IMyScoped _myScoped;

    public MySingleton(IMyScoped myScoped) {
        _myScoped = myScoped; // Runtime error, can't consume scoped from singleton!
    }
}

You can't inject scoped dependencies into singletons, because the scoped instance lifetime is tied to its scope. The instance will be disposed as soon as its scope ends, but the singleton won't be aware of that. Still, oftentimes it's necessary to use a scoped class from a singleton, e.g. from a background service.

The solution promoted by everyone is to create a scope on demand using IServiceScopeFactory:

public class MySingleton: IMySingleton
{
    private readonly IServiceScopeFactory _scopeFactory;

    public MySingleton(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public void DoWork()
    {
        using (var scope = _scopeFactory.CreateScope())
        {
            var myScoped = scope.ServiceProvider.GetRequiredService<IMyScoped>();
            myScoped.DoScopedWork();
        }
    }
}

IServiceProvider is another alternative with no meaningful difference, the result will be functionally identical:

public class MySingleton: IMySingleton
{
    private readonly IServiceProvider _serviceProvider;

    public SingletonService(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public void DoWork()
    {
        using (var scope = _serviceProvider.CreateScope())
        {
            var myScoped = scope.ServiceProvider.GetRequiredService<IMyScoped>();
            myScoped.DoScopedWork();
        }
    }
}

Unfortunately, both these approaches are a textbook example of the Service Locator pattern, and its disadvantages are well known:

IMyScoped dependency no longer arrives as a constructor param, but resolves on the method with whatever GetRequiredService has instead. This makes it difficult to swap IMyScoped implementation, either for tests or when business logic demands it. It's still possible to swap it by creating a mock of IServiceScopeFactory that would have a mocked GetRequiredService<MyScoped> returning a new implementation, but it's tedious and I'm yet to see it in the wild.
The dependency is now hidden. IMyScoped no longer appears in the constructor, its usage is spread across singleton methods. The example above has only one such instance, but in a real application there will be much more.

— No big deal, I need it just once and never again, so the blast radius is limited.

This first case establishes a precedent and an example for other developers. Soon your codebase will be littered with scope.ServiceProvider.GetRequiredService calls. If you won't do it, your coworkers will. If you don't want or can't rule your codebase with an iron hand, it will happen. A developer with a task and an estimate often has a narrow... scope. To complete the task, they will get it from the factory without thinking too much.

To Microsoft's credit, they actually discourage Service Locator pattern in their documentation, but do a poor job doing it. The ServiceProvider approach is ubiquituos at this point, and perpetuated so many times.

A Better Approach

My solution is to add a thin wrapper that allows scoped services to act like singletons:

class MyWrappedScoped: IMyScoped {
    private readonly IServiceScopeFactory _factory;

    public MyWrappedScoped(IServiceScopeFactory factory) {
        _factory = factory;
    }

    private TResult Forward<TResult>(Func<IMyScoped, TResult> action) {
        using var scope = _factory.CreateScope();
        var inner = scope.ServiceProvider.GetRequiredService<IMyScoped>();
        return action(inner);
    }

    public void DoScopedWork() {
        Forward(service => service.DoScopedWork());
    }
}

Async version is trivially doable with a pinch of async/awaits (.NET Core 3.0+):

class MyWrappedScoped: IMyScoped {
    private readonly IServiceScopeFactory _factory;

    public MyWrappedScoped(IServiceScopeFactory factory) {
        _factory = factory;
    }

    private async Task<TResult> Forward<TResult>(Func<IMyScoped, Task<TResult>> action) {
        await using var scope = _factory.CreateAsyncScope();
        var inner = scope.ServiceProvider.GetRequiredService<IMyScoped>();
        return await action(inner);
    }

    public async Task DoScopedWork() {
        return await Forward(service => service.DoScopedWork());
    }
}

No magic here. The wrapper does not eliminate Service Locator, but its handling is localized in the wrapper, allowing IMyScoped usage from singletons.

The solution comes with a price. First, it requires some boilerplate. If IMyScoped has a lot of methods, it can become tedious. Maybe I'll come up with automatic wiring later. Another potential drawback is that if you need to use both the wrapped and the original scoped service, DI becomes confused by which one to resolve. This can be mitigated with keyed services:

    builder.Service.AddKeyedScoped<IMyScoped, MyScoped>("scoped");
    builder.Service.AddKeyedScoped<IMyScoped, MyWrappedScoped>("wrapped");

And the Forward method now looks like this:

private TResult Forward<TResult>(Func<IMyScoped, TResult> action) {
    using var scope = _factory.CreateScope();
    var inner = scope.ServiceProvider.GetRequiredKeyedService<IMyScoped>("scoped");
    return action(inner);
}

It can then be used like this:

class MySingleton: IMySingleton {
    private IMyScoped _myScoped;

    public MySingleton([FromKeyedService("wrapped")] IMyScoped myScoped) {
        _myScoped = myScoped; // ok
    }
}

Not perfect, but still better than Service Locator.

Conclusion

"How to consume a scoped service from a singleton?" — use IServiceScopeFactory.

"How to consume a scoped service from a singleton without messing up my codebase?" — use the wrapper.

"Should I consume a scoped service from a singleton?" — most probably not, but sometimes there are no other options.

Originally posted on my website.

Boy Scout Rule In Programming and Its Limitations

Anton — Sun, 23 Feb 2025 14:44:24 +0000

In programming, there is a practice called the Boy Scout Rule: leave the code cleaner than it was when you opened it. When working on a task, take a look around, and if there are any problems in the surrounding code, try to fix them. In commercial software development, this rule is considered controversial and not everyone likes it, but I believe it could be beneficial both for the team and for the code base if you take its limitations into account.

The rule is often disliked by process purists, because it by definition goes beyond a task scope and introduces code changes that have no immediate value for business (just like any refactoring). YMMV, but I've never had success with "refactoring stories" or "engineering tasks". They are usually a hard sell and don't get much enthusiasm from product owners, because they don't add immediate business value. Still, every long-living project accumulates technical debt over time, and it should be dealt with eventually. The notorious "fast-paced environment" that was mentioned in the last job opening you applied is not merely a figure of speech. Chances are, you're working in one. It means that you and your team don't always have time to make everything nice and clean. When there is time pressure (and there usually is) you have to take shortcuts, and it's better to deal with them before they become a problem severe enough to account for a dedicated task. Boyscouting is one way to do that.

In addition to helping with the tech debt issue, boyscouting has some nice side effects:

Fosters the ownership mindset and craftsmanship

One problem that occurs especially with junior devs is tunnel vision. They think about code only in the context of their assigned task and prefer not to touch surrounding code even if it's bad, either because they don't see any issues with it, are afraid to change it, or because it's not "their" code and they don't have the right to touch it. This is not a right mindset. While there are always team members that better understand certain parts of code (e.g. because they implemented it), code ownership and responsibility should be shared across the team. After introducing and encouraging boyscouting I noticed that my devs show more initiative in identifying and solving problems, and just generally better reason about code.
Helps preventing "broken windows syndrome"

When the code base is sloppy, it tends to become sloppier over time. It's a signal that code quality is not an important metric and actually discourages cleaning things up, prioritizing churning new features as fast as possible instead. With boyscouting, code quality improves over time, and it sends a completely different message. "Code quality should improve over time" is actually a very powerful idea. As far as I know, it was first formalized in Google code review guidelines, a document that stirred the dev community quite a bit when it was released. Google guidelines are not for everyone, but there are a couple of nice bits I agree with, and the idea that the quality should improve over time is one of them. In practice it means that I'll accept a PR even if it (non-dramatically) exceeds the initial task scope, if the project will get to a better overall shape after the merge.

A wonderful art of Kolja Wilcke that hits a bit too close to home

Limitations

Requires good Git discipline

Ideally, every PR should be reviewable per-commit, and each commit should be self-contained and have a clear scope. In practice this doesn't always happen, and PRs could be difficult to review. Still OK if the PR is not too large.
Large refactoring still require a separate task with a separate time slot

Boyscouting should be local and limited, and it's the responsibility both of an author and a reviewer to maintain a focused scope. It will not work for large and time-consuming refactorings, but will work just fine for smaller things such as code smells.

How many unrelated changes are too many? Depends on the team. This is roughly what we do in mine:

Code style changes (newlines, indents) - zero risk, close to zero value
Fix typos - close to zero (but not zero risk), modest value
Trivial refactorings, e.g. getting rid of nested if-else aka Pyramids of Doom --- Boy scout rule probably stops around this point
Simple refactorings, e.g. split a huge method within the scope of one class --- Some boy scouts roam here, but it's a danger zone
Everything bigger - needs a separate PR

Open source is a different story

Boyscouting issues are much less prominent when there are no time constraints. In open source development, for instance, refactorings are often encouraged.

Originally posted on my website