klod68/dependency-injection-lifetime

---

name: dependency-injection-lifetime description: "Use when choosing DI lifetimes, diagnosing a 'Cannot consume scoped service from singleton' error, or when a singleton is holding stale data from a captured DbContext. Covers Singleton vs Scoped vs Transient decision matrix, the captive dependency trap and how to detect it with ValidateScopes, IServiceScopeFactory for singletons that need scoped services, keyed services (.NET 8+), and common DI registration anti-patterns. Domain: Dependency Injection, Architecture. Level: Intermediate. Tags: dependency-injection, di, lifetime, scoped, singleton, captive-dependency."

Dependency Injection Lifetime

Problem

Choosing the wrong DI lifetime causes bugs that are subtle and hard to diagnose: stale data from singletons holding scoped state, concurrency corruption from shared mutable state, memory leaks from transient disposables never released, or the "captive dependency" trap where a long-lived service captures a short-lived one.

Lifetime Decision Matrix

| Lifetime | Instance Count | Disposed When | Use For | |----------|---------------|---------------|---------| | Singleton | One per application | App shutdown | Stateless services, caches, HttpClient factories, configuration, thread-safe shared resources | | Scoped | One per scope (HTTP request) | Scope end (request end) | DbContext, unit-of-work, per-request state, tenant context | | Transient | New every resolve | Next GC (or scope end if IDisposable) | Lightweight stateless services, factories, short-lived utilities |

Quick Decision Flow

Is the service stateless and thread-safe?
  ├── Yes → Singleton (cheapest lifetime)
  └── No → Does it hold per-request state (DbContext, user context)?
              ├── Yes → Scoped
              └── No → Transient

The Captive Dependency Trap

A captive dependency occurs when a longer-lived service captures a shorter-lived dependency:

❌ Singleton → Scoped     (singleton holds stale/shared DbContext)
❌ Singleton → Transient  (transient becomes de-facto singleton)
✅ Scoped    → Transient  (safe — transient lives within scope)
✅ Scoped    → Scoped     (safe — same scope)
✅ Singleton → Singleton  (safe — same lifetime)

Detection

.NET validates this at build time when ValidateScopes is enabled (default in Development):

builder.Host.UseDefaultServiceProvider(options =>
{
    options.ValidateScopes = true;   // Default in Development
    options.ValidateOnBuild = true;  // Catches missing registrations at startup
});

Fix: IServiceScopeFactory

When a singleton needs to resolve scoped services, create an explicit scope:

internal sealed class OrderProcessor
{
    private readonly IServiceScopeFactory _scopeFactory;
    private readonly ILogger<OrderProcessor> _logger;

    public OrderProcessor(IServiceScopeFactory scopeFactory, ILogger<OrderProcessor> logger)
    {
        ArgumentNullException.ThrowIfNull(scopeFactory);
        ArgumentNullException.ThrowIfNull(logger);
        _scopeFactory = scopeFactory;
        _logger = logger;
    }

    public async Task ProcessAsync(int orderId, CancellationToken ct)
    {
        await using var scope = _scopeFactory.CreateAsyncScope();
        var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        var order = await dbContext.Orders.FindAsync([orderId], ct);
        // ... process
    }
}

Keyed Services (.NET 8+)

Register multiple implementations of the same interface, resolved by key:

builder.Services.AddKeyedSingleton<INotifier, EmailNotifier>("email");
builder.Services.AddKeyedSingleton<INotifier, SmsNotifier>("sms");

// Resolve:
public class OrderService([FromKeyedServices("email")] INotifier notifier) { }

Registration Patterns

Prefer interface registration

// ✅ Register by interface
services.AddScoped<IOrderRepository, OrderRepository>();

// ❌ Register by concrete type
services.AddScoped<OrderRepository>();

Avoid duplicate registrations

// ❌ Registers two instances — IOrderService gets its own singleton
services.AddSingleton<OrderService>();
services.AddSingleton<IOrderService, OrderService>();

// ✅ Forward the interface to the same instance
services.AddSingleton<OrderService>();
services.AddSingleton<IOrderService>(sp => sp.GetRequiredService<OrderService>());

TryAdd for libraries

// Libraries use TryAdd — consumer registrations win
services.TryAddScoped<IOrderRepository, DefaultOrderRepository>();

Common Anti-Patterns

| Anti-Pattern | Problem | Fix | |---|---|---| | Singleton capturing DbContext | Stale/shared data, concurrency bugs | Use IServiceScopeFactory to create scope | | Transient IDisposable without scope | Memory leak — never disposed | Use Scoped or manage disposal explicitly | | Registering everything as Transient | Unnecessary allocations, no sharing | Use Singleton for stateless, thread-safe services | | Scoped service in background worker | No HTTP scope exists — throws at runtime | Create scope via IServiceScopeFactory | | Service locator (IServiceProvider.GetService in business logic) | Hidden dependencies, untestable | Inject dependencies via constructor | | Missing ValidateOnBuild | Missing registrations discovered at runtime | Enable ValidateOnBuild = true in all environments | | Multiple AddSingleton for same type | Two instances created — one per registration | Forward with sp.GetRequiredService<T>() | | new DbContext() inside a service | Bypasses DI, no scope, no disposal | Inject via constructor or scope factory |

When to Use

• Designing new services and choosing their lifetime
• Debugging "Cannot consume scoped service from singleton" errors
• Reviewing DI registrations in composition roots
• Background workers that need per-iteration scoped services

Gotchas

1. ILogger<T> is Singleton: Safe to inject anywhere — no captive dependency risk.
2. IOptions<T> vs IOptionsSnapshot<T>: IOptions<T> is singleton (reads config once); IOptionsSnapshot<T> is scoped (re-reads per request). Use IOptionsMonitor<T> for singletons that need live reload.
3. HttpClient via factory: Never register HttpClient directly — use AddHttpClient<T>() which manages handlers and lifetimes.
4. Disposal order: Scoped services are disposed in reverse registration order when the scope ends. Singletons are disposed when the host shuts down.

Related Skills

• Composition Root Pattern (where registrations live)
• Guard Clause Validation (validate constructor parameters)
• Background Hosted Service (scope creation in workers)