Dependency injection and the generic host

Lifetimes, observed

1#:package Microsoft.Extensions.Hosting@10.0.02using Microsoft.Extensions.DependencyInjection;3using Microsoft.Extensions.Hosting;4 5var builder = Host.CreateApplicationBuilder(args);6builder.Services.AddSingleton<Clock>();7builder.Services.AddScoped<UnitOfWork>();8builder.Services.AddTransient<Handler>();9using var host = builder.Build();10 11for (int request = 1; request <= 2; request++)12{13    using var scope = host.Services.CreateScope();     // what ASP.NET Core does per request14    var h1 = scope.ServiceProvider.GetRequiredService<Handler>();15    var h2 = scope.ServiceProvider.GetRequiredService<Handler>();16    Console.WriteLine($"request {request}: handlers {h1.Id}/{h2.Id}, unit of work {h1.Uow.Id}/{h2.Uow.Id}, clock {h1.Clock.Id}");17}18try { host.Services.GetRequiredService<UnitOfWork>(); }19catch (InvalidOperationException e) { Console.WriteLine(e.Message); }20 21class Clock { public string Id { get; } = Guid.NewGuid().ToString()[..4]; }22class UnitOfWork { public string Id { get; } = Guid.NewGuid().ToString()[..4]; }23class Handler(UnitOfWork uow, Clock clock)24{25    public string Id { get; } = Guid.NewGuid().ToString()[..4];26    public UnitOfWork Uow => uow;27    public Clock Clock => clock;28}

Run with DOTNET_ENVIRONMENT=Development, it printed (ids are random):

1request 1: handlers e103/c528, unit of work 8d12/8d12, clock e2ef2request 2: handlers 8709/8b8f, unit of work 371e/371e, clock e2ef3Cannot resolve scoped service 'UnitOfWork' from root provider.

Transient handlers differ every time, the scoped unit of work is shared within a request and new for the next one, and the singleton clock never changes. In the default Production environment the last line didn't appear: resolving a scoped service from the root silently returned an instance that lives as long as the app.

Rules that prevent bugs

• A service may depend only on services that live at least as long. Singleton depends on singleton; scoped on scoped or singleton; transient on anything. Breaking this creates a captive dependency: a DbContext captured by a singleton is shared across threads, which it doesn't support.
• Background work creates its own scopes. A BackgroundService is a singleton. Inject IServiceScopeFactory and create a scope per unit of work.
• Let the container dispose. Services implementing IDisposable or IAsyncDisposable are disposed when their scope (or, for singletons, the host) ends. Don't dispose injected services yourself.
• Prefer constructor injection. Calling GetService all over the code (the service locator pattern) hides dependencies and defeats validation.

The host

Host.CreateApplicationBuilder (and WebApplication.CreateBuilder for web apps) gives you Configuration layered from appsettings.json, appsettings.{Environment}.json, environment variables and the command line; Logging with console output; and Services. Classes implementing IHostedService are started when the host starts and stopped gracefully on SIGINT or SIGTERM (docker stop sends the latter), and IHostApplicationLifetime lets code react to start-up and shutdown. Bind settings to typed classes with the options pattern (services.Configure<SmtpOptions>(config.GetSection("Smtp")), then inject IOptions<SmtpOptions>).