Keyed Services in .NET – Advanced Dependency Injection Techniques

In most real-world .NET applications, you’ll eventually run into a scenario where you have multiple implementations of the same interface. Maybe you’re sending notifications via Email, SMS, and Push. Or you’re integrating with different payment gateways like Stripe and PayPal. The question is—how do you cleanly inject the right service without bloating your code with if-else logic or messy service locators?

.NET 8 introduces Keyed Services, a built-in solution that finally handles this elegantly. You can now register multiple implementations under specific keys (string, enum, etc.) and resolve exactly what you need—without hacks, custom factories, or third-party libraries.

In this article, we’ll explore what Keyed Services are, how they work, and how to use them effectively in your .NET applications. We’ll look at clean DI patterns, real-world examples, and common pitfalls to avoid. If you’ve mastered the basics of Dependency Injection, this is the next step.

Why Keyed Services?

Let’s say you have an interface like INotificationService, and multiple implementations—EmailNotificationService, SmsNotificationService, and maybe a PushNotificationService. A common question is: How do I inject just one of them where I need it, without hardcoding logic or breaking DI principles?

Before .NET 8, your options weren’t great. You could:

Inject IEnumerable<INotificationService> and manually filter the one you want
Build a custom factory that returns the right service based on a key or condition
Use the IServiceProvider and resolve services manually (which breaks DI purity)

All of these work, but they add noise, boilerplate, and are harder to test and maintain.

This is where Keyed Services come in. With a simple key (like "email" or an enum value), you can register each implementation and let the DI container handle the rest. It keeps your architecture clean and focused. You no longer need to worry about service resolution logic bleeding into your business code.

What Are Keyed Services in .NET 8?

Keyed Services are a new feature in .NET 8’s built-in Dependency Injection container. They allow you to register multiple implementations of the same interface using a unique key and resolve the exact implementation you need at runtime.

Instead of relying on workarounds like filtering IEnumerable<T> or building custom service factories, you can now associate each implementation with a key (string, enum, etc.) and inject it directly where needed.

Here’s how it works.

Registering keyed services

builder.Services.AddKeyedScoped<INotificationService, EmailNotificationService>("email");
builder.Services.AddKeyedScoped<INotificationService, SmsNotificationService>("sms");

Resolving via constructor injection

public class NotificationHandler(
    [FromKeyedServices("email")] INotificationService emailService,
    [FromKeyedServices("sms")] INotificationService smsService)
{
    public async Task HandleAsync()
    {
        await emailService.SendAsync("Hello via Email");
        await smsService.SendAsync("Hello via SMS");
    }
}

Resolving manually via `IServiceProvider`

var smsService = serviceProvider.GetKeyedService<INotificationService>("sms");
await smsService.SendAsync("SMS Message");

This approach keeps your DI setup clean, avoids service locator anti-patterns, and gives you better control over which implementation to use—especially when that decision depends on runtime logic.

Available for All Lifetimes

You can use them with any service lifetime:

builder.Services.AddKeyedSingleton<IMyService, A>("a");
builder.Services.AddKeyedScoped<IMyService, B>("b");
builder.Services.AddKeyedTransient<IMyService, C>("c");

Whether it’s Scoped for per-request logic, Singleton for shared state, or Transient for fresh instances—Keyed Services work across the board.

How We Did It Before Keyed Services

Before .NET 8, resolving multiple implementations of the same interface required workarounds. Here’s how we typically handled it.

Option 1: `IEnumerable<T>` + Filtering

You register all implementations normally:

builder.Services.AddScoped<INotificationService, EmailNotificationService>();
builder.Services.AddScoped<INotificationService, SmsNotificationService>();

Then inject all of them:

public class NotificationHandler(IEnumerable<INotificationService> services)
{
    public async Task HandleAsync()
    {
        var smsService = services.First(s => s is SmsNotificationService);
        await smsService.SendAsync("OTP via SMS");
    }
}

Problems:

Breaks encapsulation (you’re selecting logic in the consumer)
Harder to test and maintain
Fragile if you add more implementations later

Option 2: Custom Factory

You build a factory that knows which service to return based on some key:

public interface INotificationServiceFactory
{
    INotificationService Get(string key);
}

public class NotificationServiceFactory : INotificationServiceFactory
{
    private readonly IServiceProvider _provider;

    public NotificationServiceFactory(IServiceProvider provider)
    {
        _provider = provider;
    }

    public INotificationService Get(string key) =>
        key switch
        {
            "email" => _provider.GetRequiredService<EmailNotificationService>(),
            "sms" => _provider.GetRequiredService<SmsNotificationService>(),
            _ => throw new NotSupportedException("Invalid key")
        };
}

Then register and use the factory:

builder.Services.AddScoped<EmailNotificationService>();
builder.Services.AddScoped<SmsNotificationService>();
builder.Services.AddScoped<INotificationServiceFactory, NotificationServiceFactory>();

public class NotificationHandler(INotificationServiceFactory factory)
{
    public Task HandleAsync()
    {
        var service = factory.Get("sms");
        return service.SendAsync("Hello via SMS");
    }
}

Problems:

More boilerplate
Duplicates DI logic inside the factory
Hard to scale with many implementations

Keyed Services solve all of this. Cleaner registration, zero filtering, zero custom factories. Just inject what you need, when you need it.

Real-World Example: Selecting Notification Channels

Let’s build a practical use case—sending notifications through different channels like Email, SMS, and Push. Each of these has its own implementation, but all follow the same INotificationService interface.

Step 1: Define the interface

public interface INotificationService
{
    Task SendAsync(string message);
}

Step 2: Implement the interface

public class EmailNotificationService : INotificationService
{
    public Task SendAsync(string message)
    {
        Console.WriteLine($"Email: {message}");
        return Task.CompletedTask;
    }
}

public class SmsNotificationService : INotificationService
{
    public Task SendAsync(string message)
    {
        Console.WriteLine($"SMS: {message}");
        return Task.CompletedTask;
    }
}

Step 3: Register services with keys

builder.Services.AddKeyedScoped<INotificationService, EmailNotificationService>("email");
builder.Services.AddKeyedScoped<INotificationService, SmsNotificationService>("sms");

Step 4: Inject and use them

public class NotificationProcessor(
    [FromKeyedServices("email")] INotificationService emailService,
    [FromKeyedServices("sms")] INotificationService smsService)
{
    public async Task ProcessAsync()
    {
        await emailService.SendAsync("Welcome Email");
        await smsService.SendAsync("OTP via SMS");
    }
}

Now your application knows exactly which implementation to use—no conditionals, no service locator hacks. Just clean DI with runtime flexibility.

You can also go one step further and resolve based on a user’s preference or config:

public class DynamicNotificationHandler(IServiceProvider provider)
{
    public async Task SendAsync(string channel, string message)
    {
        var service = provider.GetKeyedService<INotificationService>(channel);
        if (service is null) throw new InvalidOperationException("Unsupported channel");

        await service.SendAsync(message);
    }
}

This setup is ideal for multi-channel systems where the target changes at runtime.

Using Enums as Keys - Best Practice

Using string keys works, but it’s easy to make mistakes—typos, missing constants, or poor discoverability. A cleaner and safer alternative is to use enums as keys. This brings type safety and better code readability.

Define the enum

public enum NotificationChannel
{
    Email,
    Sms,
    Push
}

Register services with enum keys

builder.Services.AddKeyedScoped<INotificationService, EmailNotificationService>(NotificationChannel.Email);
builder.Services.AddKeyedScoped<INotificationService, SmsNotificationService>(NotificationChannel.Sms);

Inject services using enum keys

public class NotificationHandler(
    [FromKeyedServices(NotificationChannel.Email)] INotificationService emailService,
    [FromKeyedServices(NotificationChannel.Sms)] INotificationService smsService)
{
    public async Task HandleAsync()
    {
        await emailService.SendAsync("Enum-based Email");
        await smsService.SendAsync("Enum-based SMS");
    }
}

Resolve manually with enums

var channel = NotificationChannel.Email;
var service = serviceProvider.GetKeyedService<INotificationService>(channel);
await service?.SendAsync("Using enum key");

Enums make your keyed service registrations and resolutions easier to manage, especially in large codebases where keys are reused across multiple layers. It also plays nicely with switch expressions, validation, and IntelliSense.

When (and When Not) to Use Keyed Services

Keyed Services are great—but they’re not for every situation. Use them when they add clarity and remove boilerplate. Avoid them when they introduce unnecessary complexity or tight coupling.

When to use Keyed Services

You have multiple implementations of the same interface and need to resolve one based on a condition or configuration.
Your implementation is determined at runtime (e.g., user selects a channel, environment dictates strategy).
You’re integrating with external systems (e.g., payment gateways, auth providers) that vary per tenant or use case.
You want to replace clunky service locator or factory patterns with a cleaner, DI-based solution.

When to avoid them

If you only have one implementation—no need to over-engineer it.
If you’re tempted to use the keying logic everywhere—step back and consider if a proper strategy pattern or polymorphism fits better.
If you’re passing IServiceProvider too often just to resolve keyed services—it may signal a design issue.

Keyed Services are not a replacement for clean architecture or good design. They’re a tool—use them where they improve code clarity and flexibility, not where they hide coupling or broken abstractions.

Conclusion

Keyed Services in .NET 8 bring a clean, first-class solution to a problem that’s existed for years—resolving multiple implementations of the same interface without hacks. Whether you’re dealing with notification channels, payment gateways, or multi-tenant behaviors, keyed services let you inject exactly what you need, based on simple keys like strings or enums.

They eliminate the need for custom factories, reduce if-else noise, and keep your DI setup SOLID-compliant. With constructor injection, attribute-based resolution, and built-in support in the Microsoft DI container, this feature is production-ready and easy to adopt.

Use it where it makes your architecture cleaner. Avoid it when it hides poor design. Like any powerful tool, it’s about applying it in the right context.

If this article helped simplify Dependency Injection for you, share it with your team or anyone diving into .NET 8. The new Keyed Services feature is a game-changer—let’s help more devs write cleaner, smarter code.

This article is part of my FREE .NET Web API Zero to Hero Course, where we build production-grade APIs using clean architecture, minimal APIs, and modern .NET 8 features.

👉 Check it out here: https://codewithmukesh.com/courses/dotnet-webapi-zero-to-hero/

If you found this valuable, drop a share, repost, or recommend it to a fellow dev 🙂

Keyed Services in .NET – Advanced Dependency Injection Techniques

Why Keyed Services?

What Are Keyed Services in .NET 8?

Registering keyed services

Resolving via constructor injection

Resolving manually via `IServiceProvider`

Available for All Lifetimes

How We Did It Before Keyed Services

Option 1: `IEnumerable<T>` + Filtering

Option 2: Custom Factory

Real-World Example: Selecting Notification Channels

Step 1: Define the interface

Step 2: Implement the interface

Step 3: Register services with keys

Step 4: Inject and use them

Using Enums as Keys - Best Practice

Define the enum

Register services with enum keys

Inject services using enum keys

Resolve manually with enums

When (and When Not) to Use Keyed Services

When to use Keyed Services

When to avoid them

Conclusion

Level Up Your .NET Skills

FREE .NET Web API Course🔥

Subscribe to Mukesh's .NET Newsletter 🚀

Keyed Services in .NET – Advanced Dependency Injection Techniques

Why Keyed Services?

What Are Keyed Services in .NET 8?

Registering keyed services

Resolving via constructor injection

Resolving manually via IServiceProvider

Available for All Lifetimes

How We Did It Before Keyed Services

Option 1: IEnumerable<T> + Filtering

Option 2: Custom Factory

Real-World Example: Selecting Notification Channels

Step 1: Define the interface

Step 2: Implement the interface

Step 3: Register services with keys

Step 4: Inject and use them

Using Enums as Keys - Best Practice

Define the enum

Register services with enum keys

Inject services using enum keys

Resolve manually with enums

When (and When Not) to Use Keyed Services

When to use Keyed Services

When to avoid them

Conclusion

Level Up Your .NET Skills

FREE .NET Web API Course🔥

Subscribe to Mukesh's .NET Newsletter 🚀

Resolving manually via `IServiceProvider`

Option 1: `IEnumerable<T>` + Filtering