ASP.NET Core DI — Captive Dependencies That Exhaust Pools

Dependency Injection (DI) is one of those patterns that sounds academic until the day a tight-coupled codebase bites you in production — a change to one class breaks five others, unit tests require real databases, and swapping a third-party library means rewriting half the service layer. ASP.NET Core bakes DI into its very foundation, making it the cleanest implementation of the pattern in the .NET ecosystem.

The core idea is straightforward: instead of a class creating its own dependencies with new, those dependencies are handed to it from the outside — by the framework's IoC container. This inverts control, breaks tight coupling, and makes every class independently testable. ASP.NET Core's built-in container handles three lifetime scopes — Singleton, Scoped, and Transient — each with distinct behaviour that determines when objects are created and destroyed.

By the end of this guide you will be able to register services in Program.cs, inject them via constructors and primary constructors (C# 12+), choose the right lifetime for each service, implement advanced patterns like keyed services and factory delegates, and write unit tests that mock dependencies cleanly without touching the DI container directly.

Why ASP.NET Core DI Can Starve Your Connection Pool

Dependency injection in ASP.NET Core is a built-in container that manages object lifetimes and wiring. The core mechanic: you register types with a lifetime — Singleton, Scoped, or Transient — and the container resolves them automatically, disposing Scoped and Transient instances when their scope ends. This eliminates manual factory code but introduces a subtle trap: captive dependencies.

A captive dependency occurs when a long-lived service (Singleton) holds a reference to a shorter-lived service (Scoped or Transient). The container resolves the short-lived service once and caches it for the Singleton's lifetime, never releasing it. In practice, this means a DbContext registered as Scoped but injected into a Singleton service lives forever, accumulating connections and exhausting the pool.

Use this pattern in any ASP.NET Core application that requires structured service composition. It matters because a misconfigured lifetime silently degrades throughput: a single captive DbContext can hold a connection open for hours, causing timeouts under load. The rule: never inject a Scoped or Transient service into a Singleton — always verify lifetimes at registration time.

Why Tight Coupling Is a Silent Killer (and What DI Does About It)

Before you can appreciate DI, you need to feel the pain it eliminates. Consider an OrderService that sends a confirmation email. The naive approach is to write var emailSender = new SmtpEmailSender() right inside the service. It works — until you try to unit test OrderService and your test runner starts firing real emails. Or until your company switches from SMTP to SendGrid. Or until you need to log emails differently in staging vs production.

The root issue is that OrderService is now responsible for two things: processing orders AND knowing exactly how to construct an email sender. That violates the Single Responsibility Principle and creates a dependency on a concrete implementation rather than an abstraction.

DI fixes this by flipping the script. You define an interface — IEmailSender — that describes what an email sender does without specifying how it does it. Then OrderService declares that it needs something that implements IEmailSender, and the DI container figures out what to hand it at runtime. Your service becomes blissfully ignorant of the plumbing, and you gain the freedom to swap, mock, or extend that plumbing without touching the service at all.

// ─────────────────────────────────────────────────────────────
// BAD: Tight coupling — OrderService builds its own dependency
// ─────────────────────────────────────────────────────────────
public class SmtpEmailSender
{
    public void Send(string recipient, string subject, string body)
    {
        // Imagine a real SMTP call here
        Console.WriteLine($"[SMTP] Sending '{subject}' to {recipient}");
    }
}

public class TightlyCoupledOrderService
{
    // Hard-coded dependency: we own the SmtpEmailSender, full stop.
    // To test this class without sending real emails? Impossible.
    private readonly SmtpEmailSender _emailSender = new SmtpEmailSender();

    public void PlaceOrder(string customerEmail, string productName)
    {
        Console.WriteLine($"Order placed for: {productName}");
        _emailSender.Send(customerEmail, "Order Confirmed", $"Thanks for ordering {productName}!");
    }
}

// ─────────────────────────────────────────────────────────────
// GOOD: Loose coupling via interface + constructor injection
// ─────────────────────────────────────────────────────────────

// The contract — defines WHAT, not HOW
public interface IEmailSender
{
    void Send(string recipient, string subject, string body);
}

// Real implementation for production
public class SmtpEmailSenderV2 : IEmailSender
{
    public void Send(string recipient, string subject, string body)
    {
        Console.WriteLine($"[SMTP] Sending '{subject}' to {recipient}");
    }
}

// Fake implementation for unit tests — zero side effects
public class FakeEmailSender : IEmailSender
{
    public void Send(string recipient, string subject, string body)
    {
        Console.WriteLine($"[FAKE] Would have sent '{subject}' to {recipient}");
    }
}

// OrderService now depends on the ABSTRACTION, not the concrete class.
// The DI container (or a test) will decide what IEmailSender looks like.
public class OrderService
{
    private readonly IEmailSender _emailSender;

    // Constructor injection: the dependency is DECLARED, not created
    public OrderService(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }

    public void PlaceOrder(string customerEmail, string productName)
    {
        Console.WriteLine($"Order placed for: {productName}");
        // This line is identical whether _emailSender is SMTP, SendGrid or Fake
        _emailSender.Send(customerEmail, "Order Confirmed", $"Thanks for ordering {productName}!");
    }
}

// ─────────────────────────────────────────────────────────────
// Demo — wiring it up manually to illustrate the concept
// ─────────────────────────────────────────────────────────────
class Program
{
    static void Main()
    {
        // In production: pass the real sender
        var productionService = new OrderService(new SmtpEmailSenderV2());
        productionService.PlaceOrder("alice@example.com", "Mechanical Keyboard");

        Console.WriteLine();

        // In a unit test: pass the fake — no SMTP server needed
        var testService = new OrderService(new FakeEmailSender());
        testService.PlaceOrder("bob@example.com", "USB-C Hub");
    }
}

Registering Services in ASP.NET Core — Program.cs Is Your Wiring Diagram

In ASP.NET Core, all DI configuration lives in Program.cs (or Startup.cs in older projects). The builder.Services property gives you an IServiceCollection — think of it as a recipe book that tells the container 'when someone asks for X, hand them Y'.

There are three lifetime options when registering a service, and choosing the wrong one is one of the most common sources of subtle bugs in .NET apps:

Transient — a brand new instance every single time. Perfect for lightweight, stateless services like validators or formatters.

Scoped — one instance per HTTP request. This is the sweet spot for most business logic services and database contexts (like Entity Framework's DbContext). Every class that participates in the same request shares the same instance.

Singleton — one instance for the entire lifetime of the application. Use this for expensive-to-create, thread-safe services like configuration helpers, HTTP clients, or in-memory caches.

The container resolves the full dependency chain automatically. If OrderService needs IEmailSender which needs ILogger, you just register all three and the container figures out the construction order.

// Program.cs — the entry point for a modern ASP.NET Core app
// This is where you tell the DI container how to build your services.

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = WebApplication.CreateBuilder(args);

// ─── Register your services with the DI container ───────────────

// TRANSIENT: new instance every time IProductValidator is requested.
// Good for stateless operations — no shared state to worry about.
builder.Services.AddTransient<IProductValidator, ProductValidator>();

// SCOPED: one instance per HTTP request.
// All classes within a single request share the SAME OrderService instance.
// This is the correct lifetime for DbContext and most business services.
builder.Services.AddScoped<IOrderService, OrderService>();

// SINGLETON: one instance for the whole app lifetime.
// Every request, every thread gets the same PricingCache object.
// Only use this when the class is thread-safe and expensive to create.
builder.Services.AddSingleton<IPricingCache, InMemoryPricingCache>();

// Built-in registrations — AddControllers registers MVC services,
// which themselves have many internal DI registrations under the hood.
builder.Services.AddControllers();

var app = builder.Build();

app.UseHttpsRedirection();
app.MapControllers();
app.Run();

// ─── Service interfaces and implementations ──────────────────────

public interface IProductValidator
{
    bool IsValid(string productName, decimal price);
}

public class ProductValidator : IProductValidator
{
    public bool IsValid(string productName, decimal price)
        => !string.IsNullOrWhiteSpace(productName) && price > 0;
}

public interface IOrderService
{
    string CreateOrder(string customerEmail, string productName, decimal price);
}

public class OrderService : IOrderService
{
    private readonly IProductValidator _validator;
    private readonly IPricingCache _pricingCache;

    // The container resolves IProductValidator and IPricingCache automatically.
    // You never call 'new OrderService(...)' yourself in production code.
    public OrderService(IProductValidator validator, IPricingCache pricingCache)
    {
        _validator = validator;
        _pricingCache = pricingCache;
    }

    public string CreateOrder(string customerEmail, string productName, decimal price)
    {
        if (!_validator.IsValid(productName, price))
            return "Order rejected: invalid product data.";

        // Use the cached price if available, otherwise use provided price
        var finalPrice = _pricingCache.GetPrice(productName) ?? price;
        return $"Order created for {customerEmail}: {productName} at ${finalPrice:F2}";
    }
}

public interface IPricingCache
{
    decimal? GetPrice(string productName);
}

public class InMemoryPricingCache : IPricingCache
{
    // Singleton means this dictionary is shared across all requests.
    // Thread safety matters here — in real code consider ConcurrentDictionary.
    private readonly Dictionary<string, decimal> _prices = new()
    {
        { "Mechanical Keyboard", 129.99m },
        { "USB-C Hub", 49.99m }
    };

    public decimal? GetPrice(string productName)
        => _prices.TryGetValue(productName, out var price) ? price : null;
}

// ─── Controller that uses OrderService via DI ────────────────────
[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private readonly IOrderService _orderService;

    // ASP.NET Core sees this constructor and asks the DI container
    // to supply an IOrderService. It creates one (Scoped), injects it here,
    // and disposes it at the end of this HTTP request.
    public OrdersController(IOrderService orderService)
    {
        _orderService = orderService;
    }

    [HttpPost]
    public IActionResult PlaceOrder([FromBody] PlaceOrderRequest request)
    {
        var result = _orderService.CreateOrder(
            request.CustomerEmail,
            request.ProductName,
            request.Price
        );
        return Ok(new { message = result });
    }
}

public record PlaceOrderRequest(string CustomerEmail, string ProductName, decimal Price);

Service Lifetimes in Action — Seeing the Difference With Real Output

Reading about lifetimes is one thing. Watching them behave differently in a running app is what makes it truly stick. The best way to see lifetime differences is to inject a service into multiple places within the same request and check whether the instances are the same object or different ones.

A unique ID generated at construction time is a perfect diagnostic tool for this. If two classes receive the same ID, they got the same instance. Different IDs mean different instances.

This also reveals a critical real-world implication: if you use a Transient service that holds some state and you expect state changes in one part of the request to be visible in another, you'll be silently surprised — Transient creates a new instance each time, so that state doesn't travel. Scoped is usually what you actually want for request-level state sharing.

// A self-contained console app that mimics what ASP.NET Core DI does internally.
// Run this to SEE the lifetime differences with your own eyes.

using Microsoft.Extensions.DependencyInjection;

// ─── Service Definitions ─────────────────────────────────────────

public interface ITransientCounter { string InstanceId { get; } }
public interface IScopedCounter   { string InstanceId { get; } }
public interface ISingletonCounter { string InstanceId { get; } }

// Each service generates a unique short ID when constructed.
// If two injections share an ID, they're the same instance.
public class TransientCounter : ITransientCounter
{
    public string InstanceId { get; } = Guid.NewGuid().ToString()[..8];
    public TransientCounter() => Console.WriteLine($"  [Transient CREATED] id={InstanceId}");
}

public class ScopedCounter : IScopedCounter
{
    public string InstanceId { get; } = Guid.NewGuid().ToString()[..8];
    public ScopedCounter() => Console.WriteLine($"  [Scoped CREATED]   id={InstanceId}");
}

public class SingletonCounter : ISingletonCounter
{
    public string InstanceId { get; } = Guid.NewGuid().ToString()[..8];
    public SingletonCounter() => Console.WriteLine($"  [Singleton CREATED] id={InstanceId}");
}

// ─── A service that depends on all three ─────────────────────────
public class ReportService
{
    private readonly ITransientCounter _transient;
    private readonly IScopedCounter    _scoped;
    private readonly ISingletonCounter _singleton;

    public ReportService(
        ITransientCounter transient,
        IScopedCounter scoped,
        ISingletonCounter singleton)
    {
        _transient = transient;
        _scoped    = scoped;
        _singleton = singleton;
    }

    public void PrintIds(string label)
    {
        Console.WriteLine($"  {label}:");
        Console.WriteLine($"    Transient  id = {_transient.InstanceId}");
        Console.WriteLine($"    Scoped     id = {_scoped.InstanceId}");
        Console.WriteLine($"    Singleton  id = {_singleton.InstanceId}");
    }
}

// ─── Wiring & Demo ───────────────────────────────────────────────
var services = new ServiceCollection();
services.AddTransient<ITransientCounter, TransientCounter>();
services.AddScoped<IScopedCounter,       ScopedCounter>();
services.AddSingleton<ISingletonCounter, SingletonCounter>();
services.AddTransient<ReportService>(); // ReportService itself is Transient for this demo

var rootProvider = services.BuildServiceProvider();

Console.WriteLine("=== SIMULATED REQUEST 1 ===");
using (var scope1 = rootProvider.CreateScope())
{
    // Resolve ReportService TWICE within the same scope (same simulated request)
    var reportA = scope1.ServiceProvider.GetRequiredService<ReportService>();
    var reportB = scope1.ServiceProvider.GetRequiredService<ReportService>();

    reportA.PrintIds("ReportA (first resolve in request 1)");
    reportB.PrintIds("ReportB (second resolve in request 1)");

    Console.WriteLine();
    Console.WriteLine("  SAME Scoped instance in request 1?   " +
        (reportA.GetType().GetField("_scoped",
            System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance)
            ?.GetValue(reportA) is IScopedCounter s1 &&
         reportB.GetType().GetField("_scoped",
            System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance)
            ?.GetValue(reportB) is IScopedCounter s2 &&
         s1.InstanceId == s2.InstanceId ? "YES ✓" : "NO ✗"));
}

Console.WriteLine();
Console.WriteLine("=== SIMULATED REQUEST 2 ===");
using (var scope2 = rootProvider.CreateScope())
{
    var reportC = scope2.ServiceProvider.GetRequiredService<ReportService>();
    reportC.PrintIds("ReportC (first resolve in request 2)");
}

Advanced Patterns — Keyed Services, Factory Injection and IServiceScopeFactory

## IServiceScopeFactory: The Correct Pattern for Scoped Dependencies in Singletons

When you need a scoped service (like DbContext) inside a singleton or background service, never inject the scoped service directly — that would make it a captive dependency, effectively turning it into a singleton and causing stale data or concurrency issues. Instead, inject IServiceScopeFactory and create a scope per operation.

```csharp public class DataCleanupService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory; private readonly ILogger<DataCleanupService> _logger;

public DataCleanupService(IServiceScopeFactory scopeFactory, ILogger<DataCleanupService> logger) { _scopeFactory = scopeFactory; _logger = logger; }

protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { using (var scope = _scopeFactory.CreateScope()) { var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>(); var staleRecords = await dbContext.Records .Where(r => r.ExpiresAt < DateTime.UtcNow) .ToListAsync(stoppingToken);

dbContext.Records.RemoveRange(staleRecords); await dbContext.SaveChangesAsync(stoppingToken);

_logger.LogInformation("Cleaned {Count} stale records", staleRecords.Count); }

await Task.Delay(TimeSpan.FromHours(1), stoppingToken); } } } ```

Key points: - Always dispose the scope after use (the using block ensures this). - Each iteration gets a fresh DbContext — no stale tracking, no concurrency nightmares. - Do not cache the scope or the scoped service across iterations.

## Factory Delegate: Runtime Parameters the Container Can't Know

When you need to pass parameters that are only known at runtime (e.g., tenant ID, connection string, user context), register a factory delegate that takes IServiceProvider and returns your service.

```csharp // Registration services.AddScoped<ITenantService>(sp => { var tenantId = sp.GetRequiredService<ITenantContext>().TenantId; return new TenantService(tenantId, sp.GetRequiredService<ILogger<TenantService>>()); });

// Or as a named factory services.AddSingleton<Func<string, ITenantService>>(sp => tenantId => { var logger = sp.GetRequiredService<ILogger<TenantService>>(); return new TenantService(tenantId, logger); }); ```

When to use: - The service needs a value that changes per request or per operation. - You want to avoid injecting IServiceProvider into your business logic. - The factory itself is registered in DI, so it can resolve other dependencies.

## ActivatorUtilities.CreateInstance: Hybrid Construction for Plugins

When you need to instantiate a class that has some dependencies from DI and some parameters you provide at runtime (e.g., plugin activation, dynamic dispatch), use ActivatorUtilities.CreateInstance.

```csharp public class PluginHost { private readonly IServiceProvider _serviceProvider;

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

public IPlugin ActivatePlugin(Type pluginType, string configData) { // configData is passed directly; other deps come from DI return (IPlugin)ActivatorUtilities.CreateInstance( _serviceProvider, pluginType, new object[] { configData }); } }

// Plugin constructor public class EmailPlugin : IPlugin { public EmailPlugin(string configData, IEmailSender sender, ILogger<EmailPlugin> logger) { // configData from caller, sender and logger from DI } } ```

Rules: - The container resolves all parameters it can; your provided arguments fill the rest. - If a parameter type matches both a provided argument and a registered service, your argument wins. - Great for plugin systems, strategy pattern, or any dynamic instantiation.

## Named/Keyed Services (.NET 8+): Multiple Implementations Without Service Locator

Before .NET 8, you had to use IEnumerable<T> or a service locator to choose between multiple implementations. Keyed services give you clean, compile-time-safe selection.

```csharp // Registration services.AddKeyedSingleton<IPaymentProcessor, StripeProcessor>("Stripe"); services.AddKeyedSingleton<IPaymentProcessor, PayPalProcessor>("PayPal"); services.AddKeyedSingleton<IPaymentProcessor, SquareProcessor>("Square");

// Consumption via [FromKeyedServices] public class CheckoutService { private readonly IPaymentProcessor _processor;

public CheckoutService([FromKeyedServices("Stripe")] IPaymentProcessor processor) { _processor = processor; } }

// Or resolve at runtime with a factory services.AddSingleton<IPaymentProcessorFactory>(sp => processorType => { return sp.GetRequiredKeyedService<IPaymentProcessor>(processorType); }); ```

Benefits: - No manual switch or if-else chains. - The container manages the mapping; your code just declares what it needs. - Works with AddKeyedSingleton, AddKeyedScoped, AddKeyedTransient.

## The Service Locator Anti-Pattern: When It's Actually OK

Injecting IServiceProvider into your service class is almost always a code smell. It hides dependencies, makes testing harder, and can lead to runtime errors that would otherwise be caught at startup.

Red flags: - You're using GetRequiredService inside a method to resolve services on the fly. - Your constructor takes only IServiceProvider. - You're building a "smart" service that decides which implementation to use based on runtime data.

When it's acceptable: - Generic dispatchers: A message router that resolves handlers by message type. - Plugin hosts: Where the set of implementations is dynamic and loaded from assemblies. - Lazy initialization: When a dependency is expensive to create and may not be needed. - Framework infrastructure: The DI container itself, or libraries like IMediator.

```csharp // Acceptable use: generic dispatcher public class CommandDispatcher { private readonly IServiceProvider _serviceProvider;

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

public async Task Dispatch<TCommand>(TCommand command) where TCommand : ICommand { var handler = _serviceProvider.GetRequiredService<ICommandHandler<TCommand>>(); await handler.Handle(command); } } ```

Rule of thumb: If you can replace IServiceProvider with a specific interface (like ICommandHandlerFactory), do it. If the number of possible resolutions is unbounded or dynamic, IServiceProvider is the pragmatic choice.

// Demonstrates three advanced DI patterns you'll encounter in real projects.
// Designed for .NET 8+ for the Keyed Services feature.

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

// ─── Pattern 1: Keyed Services (.NET 8+) ─────────────────────────

public interface IPaymentProcessor
{
    string ProcessPayment(decimal amount);
}

public class StripePaymentProcessor : IPaymentProcessor
{
    public string ProcessPayment(decimal amount)
        => $"[Stripe] Charged ${amount:F2} via Stripe API";
}

public class PayPalPaymentProcessor : IPaymentProcessor
{
    public string ProcessPayment(decimal amount)
        => $"[PayPal] Charged ${amount:F2} via PayPal API";
}

// ─── Pattern 2: Factory Function Registration ─────────────────────

public class DatabaseConnectionService
{
    public string ConnectionString { get; }

    // This service needs a connection string that comes from config at runtime
    public DatabaseConnectionService(string connectionString)
    {
        ConnectionString = connectionString;
        Console.WriteLine($"  [DbConnection] Created with: {connectionString}");
    }
}

// ─── Pattern 3: IServiceScopeFactory in a Singleton ───────────────

public class OrderCleanupBackgroundService : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;

    // We inject IServiceScopeFactory (which IS a Singleton) — safe!
    // We do NOT inject IOrderRepository (which is Scoped) directly — that would be a bug.
    public OrderCleanupBackgroundService(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            Console.WriteLine("\n[BackgroundService] Starting cleanup cycle...");

            // Create a scope manually — this mimics what ASP.NET Core
            // does automatically for each HTTP request.
            using (var scope = _scopeFactory.CreateScope())
            {
                // Now safely resolve the Scoped service within our controlled scope
                var repository = scope.ServiceProvider
                    .GetRequiredService<IOrderRepository>();

                await repository.DeleteExpiredOrdersAsync();

                // When 'using' block exits, scope is disposed,
                // and so is the Scoped IOrderRepository instance.
            }

            await Task.Delay(TimeSpan.FromSeconds(10), stoppingToken);
        }
    }
}

public interface IOrderRepository
{
    Task DeleteExpiredOrdersAsync();
}

public class SqlOrderRepository : IOrderRepository
{
    public async Task DeleteExpiredOrdersAsync()
    {
        await Task.Delay(50); // Simulates a DB call
        Console.WriteLine("  [SqlOrderRepository] Deleted expired orders from database.");
    }
}

// ─── Wiring everything up ─────────────────────────────────────────
var builder = Host.CreateApplicationBuilder(args);

// Keyed registrations — same interface, two keys
builder.Services.AddKeyedScoped<IPaymentProcessor, StripePaymentProcessor>("stripe");
builder.Services.AddKeyedScoped<IPaymentProcessor, PayPalPaymentProcessor>("paypal");

// Factory function — lambda provides the runtime connection string
builder.Services.AddScoped<DatabaseConnectionService>(serviceProvider =>
{
    // In real code, you'd pull this from IConfiguration:
    // var config = serviceProvider.GetRequiredService<IConfiguration>();
    // var connStr = config.GetConnectionString("Default");
    var connStr = "Server=prod-db;Database=orders;Trusted_Connection=true";
    return new DatabaseConnectionService(connStr);
});

// Scoped repository + Singleton background service using scope factory
builder.Services.AddScoped<IOrderRepository, SqlOrderRepository>();
builder.Services.AddHostedService<OrderCleanupBackgroundService>();

var host = builder.Build();

// ─── Demo: Resolving keyed services ──────────────────────────────
using var demoScope = host.Services.CreateScope();
var sp = demoScope.ServiceProvider;

// [FromKeyedServices("stripe")] attribute does this automatically in controllers
var stripeProcessor = sp.GetRequiredKeyedService<IPaymentProcessor>("stripe");
var paypalProcessor = sp.GetRequiredKeyedService<IPaymentProcessor>("paypal");

Console.WriteLine(stripeProcessor.ProcessPayment(99.99m));
Console.WriteLine(paypalProcessor.ProcessPayment(49.50m));

var dbService = sp.GetRequiredService<DatabaseConnectionService>();
Console.WriteLine($"  Connection string in use: {dbService.ConnectionString}");

// Run the host briefly to see background service fire
await host.StartAsync();
await Task.Delay(2000);
await host.StopAsync();

Testing with Dependency Injection — Mocking, Integration Tests, and Validation

DI's biggest win is testability. When a service declares its dependencies via interfaces in constructor, you can swap real implementations for mocks or stubs in tests. This section covers three testing strategies that every senior engineer uses.

Unit Testing: Use a mocking framework like Moq to inject fake dependencies. Since your service depends only on interfaces, you can verify it calls the right methods with the right parameters without setting up databases or network calls.

Integration Testing with WebApplicationFactory: ASP.NET Core provides WebApplicationFactory<T> that creates an in-memory test server with a configurable DI container. You can replace specific services with test doubles (e.g., fake email sender) while keeping the rest of the real pipeline. This is the recommended approach for testing controllers and middleware.

Container Validation: In development, enable scoped validation by calling builder.Services.BuildServiceProvider(validateScopes: true). This throws at startup if it detects a Singleton with Scoped dependencies — catching captive dependencies before they reach production. For integration tests, you can also validate the container's configuration by resolving each service and verifying no exceptions.

// ─────────────────────────────────────────────────────────────
// Unit Test: Mocking dependencies with Moq
// ─────────────────────────────────────────────────────────────
using Moq;
using Xunit;

public class OrderServiceTests
{
    [Fact]
    public void PlaceOrder_CallsEmailSenderWithCorrectParameters()
    {
        // Arrange
        var mockSender = new Mock<IEmailSender>();
        var service = new OrderService(mockSender.Object);

        // Act
        service.PlaceOrder("alice@example.com", "Keyboard");

        // Assert
        mockSender.Verify(s => s.Send(
            "alice@example.com",
            "Order Confirmed",
            It.Is<string>(body => body.Contains("Keyboard"))),
            Times.Once);
    }
}

// ─────────────────────────────────────────────────────────────
// Integration Test: Using WebApplicationFactory to replace services
// ─────────────────────────────────────────────────────────────
using Microsoft.AspNetCore.Mvc.Testing;
using Microsoft.Extensions.DependencyInjection;

public class OrdersControllerIntegrationTests
    : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly WebApplicationFactory<Program> _factory;

    public OrdersControllerIntegrationTests(WebApplicationFactory<Program> factory)
    {
        _factory = factory.WithWebHostBuilder(builder =>
        {
            // Override the DI container for testing
            builder.ConfigureServices(services =>
            {
                // Remove the real email sender, add a fake one
                services.RemoveAll<IEmailSender>();
                services.AddSingleton<IEmailSender, FakeEmailSender>();
            });
        });
    }

    [Fact]
    public async Task PostOrder_ReturnsSuccess_WithFakeEmailSender()
    {
        // Arrange
        var client = _factory.CreateClient();
        var request = new { CustomerEmail = "test@test.com", ProductName = "Mouse", Price = 29.99m };

        // Act
        var response = await client.PostAsJsonAsync("/api/orders", request);

        // Assert
        response.EnsureSuccessStatusCode();
        var content = await response.Content.ReadFromJsonAsync<OrderResponse>();
        Assert.Contains("Order created", content.Message);
    }
}

// ─────────────────────────────────────────────────────────────
// Container Validation: Catch captive dependencies at startup
// ─────────────────────────────────────────────────────────────
// In Program.cs:
// var builder = WebApplication.CreateBuilder(args);
// ... service registrations ...
// if (builder.Environment.IsDevelopment())
// {
//     builder.Services.BuildServiceProvider(validateScopes: true);
// }
// var app = builder.Build();

Constructor Injection: The Only Pattern You Need — Here's Why

You've seen classes with five or six services injected via constructor. That's fine — don't let anyone tell you it's a code smell. Constructor injection is the simplest and most reliable way to see your dependencies at compile time. The moment you switch to property injection or method injection, you lose that compile-time guarantee. If a constructor parameter is missing, your app fails fast at startup, not at 3 AM when a user triggers a specific code path. ASP.NET Core resolves all constructor dependencies automatically when it activates the class. If it can't resolve one, you get an InvalidOperationException during container resolution, not a null reference later. Always favor constructor injection over any other pattern. Your unit tests will thank you, and your production logs will stop hiding missing dependencies.

// io.thecodeforge
public class OrderService
{
    private readonly IOrderRepository _repo;
    private readonly INotificationService _notifier;
    private readonly ILogger<OrderService> _logger;

    // Constructor injection — dependencies are explicit
    public OrderService(
        IOrderRepository repo,
        INotificationService notifier,
        ILogger<OrderService> logger)
    {
        _repo = repo ?? throw new ArgumentNullException(nameof(repo));
        _notifier = notifier ?? throw new ArgumentNullException(nameof(notifier));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    public async Task<OrderResult> PlaceOrderAsync(Order order)
    {
        _logger.LogInformation("Placing order {OrderId}", order.Id);
        var saved = await _repo.SaveAsync(order);
        await _notifier.SendConfirmationAsync(order);
        return saved;
    }
}

Scope Validation Doesn't Lie — Stop Ignoring It

You deployed to staging and everything worked. Then production starts throwing exceptions about resolved scoped services from singleton consumers. That's because development mode enables scope validation by default, and your staging environment likely didn't have it. ASP.NET Core validates scopes when ValidateOnBuild is enabled. It checks that no scoped service flows into a singleton — a violation called captive dependency. When that happens, the singleton holds the scoped service for its entire lifetime, which means you get stale data, incorrect state, or outright NullReferenceExceptions. Always enable ValidateScopes in your production service collection. Add it to Program.cs with builder.Services.BuildServiceProvider( new ServiceProviderOptions { ValidateScopes = true }). Your singleton will scream at you at startup rather than silently corrupting your application state.

// io.thecodeforge
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<IShoppingCartService, ShoppingCartService>();
builder.Services.AddSingleton<ISessionManager, SessionManager>();

var app = builder.Build();

// Validate scopes in your production pipeline
var serviceProvider = app.Services;
using (var scope = serviceProvider.CreateScope())
{
    // This will throw if a scoped service is injected into a singleton
    var session = scope.ServiceProvider.GetRequiredService<ISessionManager>();
}

app.Run();
// Output when scoped service is captive in singleton:
// System.InvalidOperationException: Cannot resolve scoped service 'IShoppingCartService'
// from root provider

ValidateOnBuild and Scope Validation — Stop Captive Dependencies Reaching Production

## The Default: Silent Leaks in Production

By default, ASP.NET Core only validates captive dependencies (Scoped injected into Singleton) in the Development environment. In Production, the same misconfiguration silently leaks — your Singleton holds a Scoped instance forever, breaking per-request isolation.

```csharp // This works in Development (throws at startup), but silently leaks in Production var builder = WebApplication.CreateBuilder(args); builder.Services.AddSingleton<MySingleton>(); builder.Services.AddScoped<IScopedService, ScopedService>();

public class MySingleton { public MySingleton(IScopedService scoped) { } // Captive dependency! } ```

## ValidateOnBuild(): Catch Captive Dependencies at Startup

ValidateOnBuild throws an InvalidOperationException during host.Build() if any service cannot be constructed due to a captive dependency. The exact exception message:

> "Cannot resolve 'MySingleton' from root provider because it requires scoped service 'IScopedService'."

``csharp var builder = WebApplication.CreateBuilder(args); builder.Services.AddSingleton<MySingleton>(); builder.Services.AddScoped<IScopedService, ScopedService>(); builder.Services.Configure<HostOptions>(opts => { opts.ValidateOnBuild = true; }); var host = builder.Build(); // Throws InvalidOperationException ``

## ValidateScopes(): Separate Scope Violations

ValidateScopes catches scope violations at resolution time (e.g., resolving a Scoped service from a Singleton scope). You need both:

• ValidateOnBuild: catches captive dependencies during service graph construction
• ValidateScopes: catches runtime scope violations (e.g., resolving Scoped from root scope)

``csharp builder.Services.Configure<HostOptions>(opts => { opts.ValidateScopes = true; opts.ValidateOnBuild = true; }); ``

## Enable Both in All Environments

``csharp var builder = Host.CreateDefaultBuilder(args) .UseDefaultServiceProvider((context, opts) => { opts.ValidateScopes = true; opts.ValidateOnBuild = true; }); ``

Why you should: This catches DI misconfigurations in every environment — Development, Staging, Production. The performance cost is negligible (only at startup/resolution), and the safety gain is enormous.

## Integration Test Pattern: Catch DI Errors in CI

``csharp [Fact] public void BuildHost_ShouldNotThrow() { var host = Program.CreateHostBuilder(Array.Empty<string>()) .UseDefaultServiceProvider(opts => { opts.ValidateScopes = true; opts.ValidateOnBuild = true; }) .Build(); // If this doesn't throw, DI is valid } ``

## Named/Keyed Services (.NET 8+)

Use AddKeyedSingleton, AddKeyedScoped with IKeyedServiceProvider to register multiple implementations of the same interface without factory delegates:

```csharp builder.Services.AddKeyedSingleton<ICache, RedisCache>("redis"); builder.Services.AddKeyedSingleton<ICache, MemoryCache>("memory");

public class CacheManager { public CacheManager(IKeyedServiceProvider keyedProvider) { var redis = keyedProvider.GetRequiredKeyedService<ICache>("redis"); var memory = keyedProvider.GetRequiredKeyedService<ICache>("memory"); } } ```

## Common Captive Dependency: IHttpContextAccessor in Background Service

IHttpContextAccessor is Scoped. Injecting it into a Singleton (e.g., BackgroundService) is a classic captive dependency:

```csharp public class MyBackgroundService : BackgroundService { private readonly IHttpContextAccessor _httpContextAccessor; // Captive!

public MyBackgroundService(IHttpContextAccessor httpContextAccessor) { _httpContextAccessor = httpContextAccessor; }

protected override async Task ExecuteAsync(CancellationToken stoppingToken) { // _httpContextAccessor.HttpContext is always null here } } ```

Exception: InvalidOperationException: Cannot resolve scoped service 'IHttpContextAccessor' from root provider.

Fix: Use IServiceScopeFactory to create a scope per operation:

```csharp public class MyBackgroundService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory;

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

protected override async Task ExecuteAsync(CancellationToken stoppingToken) { using var scope = _scopeFactory.CreateScope(); var httpContextAccessor = scope.ServiceProvider.GetRequiredService<IHttpContextAccessor>(); // Now httpContextAccessor.HttpContext is valid } } ```