Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to get IReadOnlyDictionary<,> of keyed services #95476

Open
MikeAlhayek opened this issue Nov 30, 2023 · 7 comments
Open

Add a way to get IReadOnlyDictionary<,> of keyed services #95476

MikeAlhayek opened this issue Nov 30, 2023 · 7 comments
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-Extensions-DependencyInjection needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration
Milestone

Comments

@MikeAlhayek
Copy link

MikeAlhayek commented Nov 30, 2023

.NET 8 introduced a way to register keyed services which is great addition. However, what if one wants to get a list of registered services along with their key. For example, during run time, I want to present the user a menu of some sort with all available services. The user will select the default service to use for the app. Without a way to expose the registered key, there is no real easy way to identify the keyed service and its key.

I think the missing piece here is the ability to be able to inject IReadOnlyDictionary<object?, object> which it'll be resolved by the IoC container. Alternatively, we can have a service with something like this

public interface IKeyedServiceProvider
{
    IReadOnlyDictionary<object?, T> GetServices<T>();
}

Along with extensions similar to the following

IReadOnlyDictionary<TKey, T> GetServices<TKey, T>()

Or add an extension on IServiceProvider that allows the above 2 methods.

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Nov 30, 2023
@ghost
Copy link

ghost commented Nov 30, 2023

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

Issue Details

.net 8 introduced a way to register keyed services which is great. However, what if one wants to get a list of services along with it's key. For example, during run time, I want to present the user a menu of available services. The user will select the default service to use. Without a way to expose the registration key, there is no real easy way to identify the keyed service.

I think the missing piece here is the ability to be able to inject IDictionary<object, object> which it'll be resolved by the IoC container.

Author: MikeAlhayek
Assignees: -
Labels:

untriaged, area-Extensions-DependencyInjection

Milestone: -

@davidfowl
Copy link
Member

I don’t think we’d do it that way but I agree with the sentiment that this feature is missing.

@MikeAlhayek
Copy link
Author

MikeAlhayek commented Dec 2, 2023

@davidfowl thanks for your comment. Other using a dictionary, how would you do it?

I updates my Issue by providing alternative solution using a provider.

@MikeAlhayek MikeAlhayek changed the title Add a way to resolve IDictionary<,> from keyed service Add a way to get IReadOnlyDictionary<,> of keyed services Dec 3, 2023
@jtkech
Copy link

jtkech commented Dec 3, 2023

@MikeAlhayek

Your dictionary may need to take into account that for the same service key and service type multiple services may have been registered, with different implementation types, instances or factories but with the same service type.

@steveharter steveharter added the api-suggestion Early API idea and discussion, it is NOT ready for implementation label Jan 8, 2024
@steveharter
Copy link
Member

The proposal here adds to the existing interface IKeyedServiceProvider which we can't really do. Although it is possible now to add to an existing interface by leveraging DIMs or Default Interface Methods, but since DI supports .NET Framework I don't think that is available. So we'd need another interface so a provider can opt-in.

@steveharter steveharter added this to the 9.0.0 milestone Jan 8, 2024
@steveharter steveharter removed the untriaged New issue has not been triaged by the area owner label Jan 8, 2024
@steveharter
Copy link
Member

@benjaminpetit thoughts?

@hishamco
Copy link
Member

Any update on this?

@steveharter steveharter modified the milestones: 9.0.0, 10.0.0 Jul 24, 2024
@steveharter steveharter added the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-Extensions-DependencyInjection needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration
Projects
None yet
Development

No branches or pull requests

5 participants