Add Keyed Services Support to Dependency Injection

[benjaminpetit]

Related issue: #64427

Since my last proposal (https://gist.github.com/benjaminpetit/49a6b01692d0089b1d0d14558017efbc) we made some changes and took some decisions.

This PR is still in draft, but everything is working and can be reviewed. Naming is not definitive, and some exception needs to be replaced.

Changes since the proposal:

• introduced ServiceKeyAttribute: used to inject the key used to resolve the service in the constructor (see test ResolveKeyedServiceSingletonInstanceWithKeyInjection
• introduced FromKeyedServices: used to get a keyed service from DI in the constructor (see test ResolveKeyedServiceSingletonInstanceWithKeyedParameter)
• introduced the notion of "any key registration": the user can register a "catchall" key that will resolve any key. Useful to injet logger with custom category, instead of relying on open generics for example.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

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

Issue Details

---

Related issue: #64427

Since my last proposal (https://gist.github.com/benjaminpetit/49a6b01692d0089b1d0d14558017efbc) we made some changes and took some decisions.

This PR is still in draft, but everything is working and can be reviewed. Naming is not definitive, and some exception needs to be replaced.

Changes since the proposal:

• introduced ServiceKeyAttribute: used to inject the key used to resolve the service in the constructor (see test ResolveKeyedServiceSingletonInstanceWithKeyInjection
• introduced FromKeyedServices: used to get a keyed service from DI in the constructor (see test ResolveKeyedServiceSingletonInstanceWithKeyedParameter)
• introduced the notion of "any key registration": the user can register a "catchall" key that will resolve any key. Useful to injet logger with custom category, instead of relying on open generics for example.

Author:	benjaminpetit
Assignees:	benjaminpetit
Labels:	new-api-needs-documentation, area-Extensions-DependencyInjection
Milestone:	-

[tillig]

Shouldn't there be some specification tests to ensure containers that implement this are doing it right? The spec tests also indicate how the .NET team intends to use the feature (to "document" both explicit and implicit behavior requirements) so having that would be helpful.

[halter73]

Overall, I really like the approach. I'm a big fan of wrapping the key and type in ServiceIdentifier. I do think we should use string instead of object for the name. I also think we should do more to fail loudly when used with incompatible containers.

Stuff like IServiceProviderIsService support can probably come later. We should definitely fix the _realizedServices caching bug though.

[halter73]

Shouldn't it be invalid for a [ServiceKey] parameter to be a string and not an object? People will want it to alwas be a string so they can store it in a string field like you do here. I think this proves my earlier point about how it's more convenient to work with this parameter when you know it will be a string.

[benjaminpetit]

I disagree, people will not always want to use a string. And here it just works fine, not sure why we should force it to be an object, that's the responsibility of the developer.

[halter73]

What happens if someone tries to register this service using the AnyKey? Does it validate when we add the service or build the ServiceProvider? Or does it just throw an InvalidCastException when you try to resolve it?

I think we should probably at least be validating the runtime service key type is assignable to the [ServiceKey] parameter type in CallSiteFactory. This validation would make sense even if the service type had to be string.

[benjaminpetit]

It will throw InvalidCastException, that's correct. I guess we could validate the parameter type.

[benjaminpetit]

Shouldn't there be some specification tests to ensure containers that implement this are doing it right? The spec tests also indicate how the .NET team intends to use the feature (to "document" both explicit and implicit behavior requirements) so having that would be helpful.

I moved tests to the spec tests, I think they were all relevant.

[steveharter]

sealed?

[benjaminpetit]

Not sure, the developer can inherit from this attribute to use custom types for the key

[halter73]

Is that a good idea though? Could that interfere with future source generators? We could always shoot of a quick email to get API approval for sealing it. It seems safer since we could always unseal later.

[halter73]

Thanks for making the API changes I suggested. As much as I like them, we should at least send an API review email to make sure any API adjustments are approved before merging. Or better yet discuss them in tomorrow's meeting.

[steveharter]

LGTM pending some minor API approvals.