If we do keep keyed factories as the one thing that doesn't accept a null service key, we should add a test for someone incorrectly trying to add one with a null key. Sorry if I missed an existing test for this.

Are these also not required anymore?

Should this be `object? serviceKey` for pass-through support (like elsewhere in this PR)?

Should this be `object? serviceKey` for pass-through support (like elsewhere in this PR)?

Should this be `object? serviceKey` for pass-through support (like elsewhere in this PR)?

Should this be `object? serviceKey` for pass-through support (like elsewhere in this PR)?

Should this be `object? serviceKey` for pass-through support (like elsewhere in this PR)?

Should this be `object? serviceKey` for pass-through support (like elsewhere in this PR)?

This is a partial class and the other class also has the same doc which I don't think we need in both places. Also nit: extra whitespace before `/>`

@ViktorHofer PTAL at these suppressions here - these are new APIs so should we conditionally exclude them in the .cs \ .csproj to avoid these suppressions?

Is this needed? ObjectFactory.#ctor v6->v7

Typically in .ref files, there are not any `using` statements since the api gen tooling fully qualifies namespaces.

Rename this file to `ServiceIdentifier.cs`.

```suggestion CallSiteFactory.Add(ServiceIdentifier.FromServiceType(typeof(IServiceProviderIsService)), new ConstantCallSite(typeof(IServiceProviderIsService), CallSiteFactory)); CallSiteFactory.Add(ServiceIdentifier.FromServiceType(typeof(IKeyedServiceProviderIsService)), new ConstantCallSite(typeof(IServiceProviderIsService), CallSiteFactory)); ``` I now feel way more strongly that `IKeyedServiceProviderIsService` should implement `IServiceProviderIsService`. Once things like RDF and RDG start supporting `[FromKeyedServices("name")]` parameters, it's probably going to want to be able to check for the existence of both keyed and non-keyed services so bad configurations can fail at startup, and needing to resolve two different services is annoying. @captainsafia I also worry a bit about the discoverability of `IKeyedServiceProviderIsService` because no one is going to interact with `IKeyedServiceProvider` directly, only through the `GetKeyedService` extension method on `IServiceProvider`. I wonder if `IServiceProviderIsKeyedService` is more discoverable since it also starts with `IServiceProvider`. Granted `IServiceProviderIsService` is a terrible name to start from, and maybe we don't need it to be super discoverable. I feel more strongly that we should at least have `IKeyedServiceProviderIsService : IServiceProviderIsService`. I cannot imagine a container supporting detecting only keyed services.

Are there any tests for this? You need to be able to resolve the IKeyedServiceProviderIsService from the container which means it needs to be added to the CallSiteFactory in the ServiceProvider ctor like IServiceProviderIsService. We should add a specification test for this.

Can we put this in its own file please?

Nit: `ServiceCollectionServiceExtensions.Keyed.cs`

Nit: I think the convention for partial classes is to call this something like `ServiceCollectionDescriptorExtensions.Keyed.cs`. It makes it easier to find when looking for "ServiceCollectionDescriptorExtensions".

What are these suppressions are for (quick summary)? Thanks

nit: could remove auto-added change this since no other changes here.

sealed?

sealed?

nit: add sealed

Are these suppressions needed? (I couldn't find the types)

style nit\preference: I favor `Service service1 = new()` syntax and try to avoid `var` in general whenever the type isn't spelled out later in the same line, but it looks like DI uses `var` quite a bit so keeping consistency at least within each file is good. Also, consistency is not so important for tests, but at least in production code.

nit: the `unchecked` could be lower

nit: unnecessary blank line

I believe you'll need to add back the `DynamicallyAccessedMembersAttribute` here and elsewhere. The API gen tools may have removed it?

Is the removal of these attributes intentional?

nit: maybe use "match" terminology instead of "equals" and perhaps rename the arguments to `key` and `query` to convey the meaning a little more clearly

This could be `ServiceDescriptor.AnyServiceKey` or similar instead of adding a new class, to aid in discoverability. Someone may argue that this class should be named `ServiceKey`. I am ok either way. I wonder if there should be convenience APIs (perhaps extensions) for registering AnyKey services

Should this be a private type that overrides `ToString()` to return something other than "System.Object"? Maybe it could "AnyKey" or "*" instead.

This seems really bad. Doesn't this mean that a named services `Func<ServiceProviderEngineScope, object?>` could replace that of an equivalent non-named services. That could be really nasty to try to debug 😱. It also means that we always use the `CallSiteRuntimeResolver` and never upgrade to the `ILEmitResolverBuilder`. This is also fixed by adding the name to the ServiceCallSite, right?

Shouldn't we add the name to the ServiceCallSite? And to CallSiteValidator.ValidateResolution()? Right now, I don't think our CallSiteValidator is going to identity any scoped-service misusage for named services. We should add a test for this.

Nit: ```suggestion return ((ServiceType.GetHashCode() ?? 23) * 397) ^ ServiceKey.GetHashCode(); ``` Can we not use `HashCode.Combine` because of the nestandard2.0 target? `HashCode.Combine` doesn't have an unchecked block. Do we really need it here?

Do we need to add this to `IServiceProviderIsService`? I assume that the existing `IsService(Type)` method will always return false for a named service, is that right?

Do we need any of the `TryAdd` methods?

Do we have a test for `IEnumerable`-resolving named services?

Do we have a test for an open generic named service?

Since we're adding these both at once, should we just make `ISupportRequiredKeyedService` the one and only new interface you have to implement? Naturally, it'd have the normal `GetKeyedService` too. We could just call it `ISupportNamedService` :wink: It makes this method a little less complicated and saves us an interface. I cannot see why you would implement one without the other.

I'd put these with all the other ServiceCollectionServiceExtensions too.

Have we considered how we're going to prevent .NET 7 and earlier versions of our default ServiceProvider and third-party containers from misinterpreting named services? I asked about this [in the API proposal](https://github.com/dotnet/runtime/issues/64427#issuecomment-1532412173). It seems difficult, but maybe we could do something. Like, maybe for named services, you have to get the `NamedImplementationType` or the `NamedImplementationInstance` and all the normal `Implementation` getters throw.

Do we need the "key" parameter for this overload?

Why not add all these to the existing `ServiceProviderServiceExtensions` along with `GetService<T>()`, `GetRequiredService(Type)`, etc...?

Does the key need to be an object? What's the use case for anything other than a string here? Is it just so we can guarantee no conflicts with the `AnyKey`? A string is a lot easier to work with. I like "name" over "key" for this if we do go with string. It'd be nice if registering a named `IConfigureOptions<TOptions>` service would configure the corresponding named options without forcing you to register an `IConfigureNamedOptions` that gets called for options with any name. Similarly, resolving a named `IOptions<TOptions>` would be easier than resolving named options from `IOptionsMontor`. I think not doing this might be a missed opportunity, because if we wait to do it in .NET 9, it might be too breaking.

It'd be good to clean up the suppressions in this diff. Not sure why you're hitting these, but if you need some help wrangling the dotnet/runtime infra reach out to @steveharter to get some tips for working on these libraries and adding API.