[API Proposal]: Support resolving all service keys associated with keyed DI instances

[captainsafia]

Background and motivation

I'm using keyed DI to manage multiple versions of a document in a DI-based store. As part of this work, I need to implement a API that provides information to the end-user about allt the version names (aka service keys) that are associated with a give document.

I can use the GetKeyedServices<MyType>(KeyedService.AnyKey) API to retrieve all instances associated with my service type but there is no way to resolve the service key associated with each type as a result of it.

cc: @benjaminpetit

API Proposal

namespace Microsoft.Extensions.DependencyInjection;

public static class ServiceProviderKeyedServiceExtensions
{
    public static IEnumerable<object> GetKeyedServiceKeys<T>(this IServiceProvider provider)
}

API Usage

public IEnumerable<string> GetDocumentName()
{
	return services.GetKeyedServiceKeys<DocumentType>();
}

Alternative Designs

The existing GetKeyedServices extension method can be updated to return a tuple capturing the service key.

- public static IEnumerable<T> GetKeyedServices<T>(this IServiceProvider provider, object? serviceKey)
+ public static IEnumerable<(object, T)> GetKeyedServices<T>(this IServiceProvider provider, object? serviceKey)

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-dependencyinjection
See info in area-owners.md if you want to be subscribed.

[steveharter]

Thoughts @benjaminpetit ?

[benjaminpetit]

I talked with @captainsafia offline, and I think it makes sense.

But we need to decide what to do with AnyKey registration.

[0xced]

How about supporting resolving IReadOnlyDictionary<TKey,TService> instead? @dotnetjunkie shows how to do it on Stack Overflow: How to get a dictionary of keyed services in ASP.NET Core 8.

It would be nice if this feature was supported out of the box. It is more intuitive than an extension on IServiceProvider in my opinion.

[julealgon]

@0xced

How about supporting resolving IReadOnlyDictionary<TKey,TService> instead? @dotnetjunkie shows how to do it on Stack Overflow: How to get a dictionary of keyed services in ASP.NET Core 8.

It would be nice if this feature was supported out of the box. It is more intuitive than an extension on IServiceProvider in my opinion.

Returning a dictionary like this is not good because the services are already resolved, which can be incredibly wasteful if all you wanted were just the existing keys.

Unless you make it so that the instantiation only happens when actually accessing a specific key on the dictionary, which would likely require a custom dictionary implementation behind the scenes. The way Stephen does it, forces the creation of the services when the dictionary is created.

[0xced]

Unless you make it so that the instantiation only happens when actually accessing a specific key on the dictionary, which would likely require a custom dictionary implementation behind the scenes.

Maybe what you just proposed is actually a good idea? I'm not sure, happy to hear other people's opinion too.

[julealgon]

Unless you make it so that the instantiation only happens when actually accessing a specific key on the dictionary, which would likely require a custom dictionary implementation behind the scenes.

Maybe what you just proposed is actually a good idea? I'm not sure, happy to hear other people's opinion too.

Yeah, I'm not opposed to that myself. Just wanted to make sure to bring that aspect to the discussion, as a lot of flows are only interested in the keys and constructing all the actual concrete services upfront is wasteful in those scenarios.

To be clear, I've done this myself before the keyed service support was in place by using Lazy<T, TMetadata> objects and creating a custom AddTransientLazy<TService, TImplementation, TMetadata> extension that would behind the scenes also register the metadata itself with a custom container object so we could also resolve just the metadata later. In our particular case, we need to expose all existing keys for a given set of registrations so the user can pick an option in a dropdown list in the UI.

We resolved only the metadata for a given interface by requesting IEnumerable<TMetadata> after calling AddTransientLazy multiple times by implementing a custom adapter from IEnumerable<Lazy<TService, TMetadata>> to IEnumerable<TMetadata>.

[0xced]

This API proposal looks like a subset of another older API proposal: #91466