[FEATURE REQ] Support keyed DI with AddAzureClients

[Arithmomaniac]

Library name

Microsoft.Extensions.Azure

Please describe the feature.

When registering multiple services by name (using WithName()) with .AddAzureClients, you need to resolve the intended service via DI by injecting an IAzureClientFactory<TClient> so that you can invoke .CreateClient() on the named service.

It would be great if registering a dependency by name would register the client with the new keyed DI support so that instances of TClient can be injected directly. Or if that poses compatibility issues, add a new WithKey() method to do the same.

[jsquire]

Thank you for your feedback, @Arithmomaniac. We've added this to our backlog for consideration.

[jsquire]

@AlexanderSher: Would you please take a look at whether it is feasible to support the new keyed DI registration without breaking changes and advise?

[github-actions]

Hi @Arithmomaniac. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[annelo-msft]

@Arithmomaniac -- thanks for your feature request! As we look further into different approaches to enabling your scenario, it would be helpful for us to have a clear picture in our heads of what you'd like to do with keyed DI registration. Would it be possible to give us a sense of the type of app that you're building around the DI container and what scenarios/features you are looking to implement that you are unable to accomplish today without keyed registration support? Many thanks in advance for your help on this!

[Arithmomaniac]

I've moved on to other projects, but IIRC the use case was pretty similar to the one provided in the DI documentation. Suppose the following DI configuration:

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
            builder.Configuration.GetSection("PublicStorage"));
        .WithName("PublicStorage");

    clientBuilder.AddBlobServiceClient(
            builder.Configuration.GetSection("PrivateStorage"))
        .WithName("PrivateStorage");
});

Today you have to do the following:

public class HomeController : Controller
{
    private readonly ICache _bigCache;
    private readonly BlobServiceClient _publicStorage;
    private readonly BlobServiceClient _privateStorage;

    public HomeController(
        [FromKeyedServices("big")] ICache bigCache,
        IAzureClientFactory<BlobServiceClient> clientFactory)
    {
        _bigCache = bigCache;
        _publicStorage = clientFactory.CreateClient("PublicStorage");
        _privateStorage = clientFactory.CreateClient("PrivateStorage");
    }
}

I'd like to be able to do the following:

public class HomeController(
  [FromKeyedServices("big")] ICache bigCache,
  [FromKeyedServices("PublicStorage")] BlobServiceClient publicStorage,
  [FromKeyedServices("PrivateStorage")] BlobServiceClient privateStorage
) : Controller
{
}

Advantages:

• Makes it easier to pass in test doubles during testing - don't need to mock a whole client factory to return two concrete instances
• Makes it easier to use primary constructors (as shown)
• Unified, idiomatic interface for "keying" Azure and non-Azure services

[annelo-msft]

Thank you so much for the explanation, @Arithmomaniac!

Just to confirm that I am understanding correctly -- Microsoft.Extensions.Azure APIs strictly-speaking support the scenario you're interested in (adding multiple instances of a single client type to the DI service collection) via the WithName extension method. But, if we were to better integrate it with the new-in-.NET8 keyed services feature, it would have the advantages you listed as a result of better ecosystem integration. Specifically, you could then make one or more keyed services (e.g. Azure.Storage.Blobs.BlobServiceClient instances) parameters to an ASP.NET controller, which would retrieve the client(s) from the DI service collection rather than requiring you to create them new via the call to the Azure client factory.

Is that correct?

[github-actions]

Hi @Arithmomaniac. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[Arithmomaniac]

Precisely

[annelo-msft]

Looking at this as part of #46671

[abatishchev]

+1 for supporting keyed service by AddAzureClients et al

[Bouke]

While waiting for official support, here's how you can achieve the same. Instead of calling WithName, you'd call WithKey.

public static class AzureClientBuilderExtensions
{
    public static IAzureClientBuilder<TClient, TOptions> WithKey<TClient, TOptions>(
        this IAzureClientBuilder<TClient, TOptions> builder, string serviceKey)
        where TOptions : class where TClient : class
    {
        builder.WithName(serviceKey);

        var services = (IServiceCollection)builder.GetType().GetProperty("ServiceCollection")!.GetValue(builder)!;
        services.AddKeyedSingleton<TClient>(serviceKey,
            (provider, _) => provider.GetRequiredService<IAzureClientFactory<TClient>>().CreateClient(serviceKey));

        return builder;
    }
}