Resolve with serviceKey doesn't invoke factory selector

[cnshenj]

It can be reproed using DryIoc 5.4.3

new Container(
    rules =>
        rules.WithFactorySelector(
            (request, single, many) =>
            {
                // Do something here
            }));

container.Register<IFoo, Foo>(); // Default
container.Register<IFoo, Foo>("my"); // Keyed
container.Resolve<IFoo>(); // Custom factory selector invoked
container.Resolve<IFoo>("my"); // Custom factory selector NOT invoked

Slightly related, I don't like returning null to tell DryIoc to use the default factory. It's not obvious, and prevents a useful pattern like this:

// Rules.Default.FactorySelector is null so it can't be really used
var defaultFactory = Rules.Default.FactorySelector(request, single, many);
if (IsSpecialType(defaultFactory.ImplementationType))
{
    // Return a different factory
}
else
{
    return defaultFactory;
};

[dadhi]

@cnshenj Huh, ok. Will check.

[dadhi]

Seems reproducible. Thanks

[dadhi]

@cnshenj Actually, the FactorySelector was introduced to select the factory from multiple registrations without key.
Because by definition, at least in my mind, when you are providing the key, it is supposed to uniquely identify the registration.
Therefore, you did the selection of factory on your end.

But... sigh, currently we have the MS.DI keyed services where the keys can be the same for the save service type. So the keys are operating like the labels, or metadata which is supported by DryIoc and is a separate feature.

Given the current need of integration with MS.DI, let's keep this issue open and I will work on this.