Skip Scope Validation in Development on ASP.NET

If you see an error like this:

System.InvalidOperationException:
Error while validating the service descriptor '...(some service)...'
Cannot consume scoped service '...(some scoped service)...'
from singleton '...(some singleton)...'

You’re probably running in the Development environment for an ASP.NET application. The error is caused by Development having strict checks on the scope of your services.

If you’re working on a big project and are reticent to refactor others’ code because you don’t know why it is the way it is, here’s a quick fix for you. Find the Program.cs file for the application, and add the following close to the top:

// TODO: Remove this, do not commit this, it's a workaround only
if (builder.Environment.IsDevelopment())
{
    builder.Host.UseDefaultServiceProvider((context, options) =>
    {
        options.ValidateScopes = false;
        options.ValidateOnBuild = false;
    });
}

This will switch off ValidateScopes and ValidateOnBuild, getting rid of your nasty errors.

Does this always work?

I am new to C# and .NET in general, so I can’t guarantee you this always works. But it definitely works for applications that begin with this builder:

var builder = WebApplication.CreateBuilder(args);

Extra Insight

If you want to understand this a bit more deeply.

Scoping

ASP.NET has a neat feature. When you register services you can define their application “scope”. This is the lifetime of that service within the application. If your service is supposed to last for the length of the application, you can make it a “Singleton” (single instance). You can register it as “Scoped” if it can be instantiated multiple times. The two look like this:

// Multiple instances
services.AddScoped<IAssetsService, AssetsService>();

// Single instance
services.AddSingleton<ISignalRConnectionsService, SignalRConnectionsService>();

A Singleton shouldn’t use a Scoped service directly, because the Scoped service may be deleted and the Singleton will lose its reference and stop working. However, this is a shouldn’t vs can’t issue. You shouldn’t, but you can. So when you’re running in Production, this will not give you an error.

Dev mode

ASP.NET has another neat feature. You can run your application in Development mode to get better debug output. You can do that with a command like this:

dotnet run --environment Development

The problem is, in dev mode the scoping “shouldn’t” becomes a “can’t”, by default. Leading you to the error shown at the top of the article. The workaround posted at the top switches off the validation options that cause this error.

This is considered bad practice. But, practically, sometimes there are deadlines. Sometimes you need to deliver. Sometimes you need the quick shortcut for the better debug output.

Final Word

Never commit that fix; if you can, refactor your code! It’s safer in the long run. Thanks for reading! Happy C# hacking.