Why I can inject Scoped service into BackgroundService if not in development environment?

[kklldog]

Hi,

There is a strange behavior in my project.
When I inject a scoped service into my BackgroundService there is no exception be threw when BackgroundService be activated if I am not use development environment.
I can access the scoped service and call it's methods. The BackgroundService also works fine. Everything is fine.
But if I switch back to development environment then run the same code that will throw an exception as expected:
Cannot consume scoped service 'DevelopmentTest.IMyService' from singleton
This is correct behavior as my experience. All my experience and all the docmentations said:
BackgroundService will be registered as singleton and in singleton service you can not inject a scoped service directly otherwise the BackgroundService will run failed.
docmentations in micorsoft learn:
consuming-a-scoped-service-in-a-background-task
Use scoped services within a BackgroundService

So Am I wrong?
Anybody can explain me more? It confuses me a lot.
Thanks.

Sample:

    public interface IMyService
    {
        void Method1();
    }

    public class MyService: IMyService
    {
        public void Method1()
        {
            Console.WriteLine("Method1 ...");
        }
    }

    public class LongTermSerive : BackgroundService
    {
        private readonly IMyService _mySerivce;

        public LongTermSerive(IMyService mySerivce)
        {
            _mySerivce = mySerivce;
        }

        protected override Task ExecuteAsync(CancellationToken stoppingToken)
        {
            _mySerivce.Method1();

            return Task.CompletedTask;
        }
    }

using DevelopmentTest;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddScoped<IMyService, MyService>();
builder.Services.AddHostedService<LongTermSerive>();

builder.Services.AddControllers();

var app = builder.Build();

// Configure the HTTP request pipeline.

app.UseAuthorization();

app.MapControllers();

app.Run();

.NET SDKs installed:
8.0.400 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Example in Github here: DevelopmentTest

[davidfowl]

The scope service check only happens in development, originally it was done that way to save on performance at runtime and avoid breaking changes but maybe its time to always do scope validation by default. There is no scope when you inject into a background thread, its a singleton so the "scope" is top level.

See https://ankitvijay.net/2020/03/17/net-core-and-di-beware-of-captive-dependency/

[kklldog]

The scope service check only happens in development, originally it was done that way to save on performance at runtime and avoid breaking changes but maybe its time to always do scope validation by default. There is no scope when you inject into a background thread, its a singleton so the "scope" is top level.

See https://ankitvijay.net/2020/03/17/net-core-and-di-beware-of-captive-dependency/

Hi @davidfowl ,
Thanks your answer.
So
In the .NET DI system, there is no strict rule preventing Scoped services be injected into Singleton services.
Did I understand correctly?

[lilinus]

You are right.
The option to validate it can be toggled. C.f. ServiceProviderOptions.ValidateScopes.
I assume it is for performance reasons validation can be disabled.

[julealgon]

...but maybe its time to always do scope validation by default.

I like the way you think @davidfowl .

To be fair... this has come up a few times inside our teams as some devs were confused by the difference in behavior between our dev and beta environments. The vast majority of engineers are completely unaware of the scope validation step (and honestly, a lot of them are not even aware of the problem of captive dependencies in the first place...).

If the performance hit is small enough, I think it would be great to standardize this behavior and have it run everywhere.

[kklldog]

...but maybe its time to always do scope validation by default.

I like the way you think @davidfowl .

To be fair... this has come up a few times inside our teams as some devs were confused by the difference in behavior between our dev and beta environments. The vast majority of engineers are completely unaware of the scope validation step (and honestly, a lot of them are not even aware of the problem of captive dependencies in the first place...).

If the performance hit is small enough, I think it would be great to standardize this behavior and have it run everywhere.

I agree. The validation step may only effect the application startup time. I think this is not a big impact for most of projects.
Maybe the validation should be default and if the application is really care the performance then user can disable the validation by mannual.

[kklldog]

You are right. The option to validate it can be toggled. C.f. ServiceProviderOptions.ValidateScopes. I assume it is for performance reasons validation can be disabled.

Hi @lilinus
Thanks your answer.