ActivatorUtilities.CreateInstance depends on the order of constructors' definitions

[quixoticaxis]

Description

Current behavior

The effect of calling ActivatorUtilities.CreateInstance methods (any of the overloads) depends on the order in which the constructors of the type being created are defined. The instance of the class is created if constructors are defined in one order, but the creation throws if constructors are defined in reversed order (see the code below).

Expected behavior

The call throws because it failed to disambiguate the appropriate constructor. This behavior will be in-line with the behavior of Activator.CreateInstance.

Reproduction

using Microsoft.Extensions.DependencyInjection;

using static System.Console;

namespace AUCI
{
    public class A { }
    public class B { }
    public class C { }
    public class S { }

    public class Creatable
    {
        public Creatable(
            A a,
            B b,
            C c,
            S s)
        {
            WriteLine("Creatable.Long");
        }
        
        public Creatable(
            A a,
            C c,
            S s)
        {
            WriteLine("Creatable.Short");
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            var services = new ServiceCollection();
            services.AddScoped<S>();
            using var provider = services.BuildServiceProvider();

            var instance = ActivatorUtilities.CreateInstance(
                provider,
                typeof(Creatable),
                // Please, note that the order of parameters does not match the order of constructors' arguments
                new C(), new A()); 
        }       
    }
}

The code above throws when invoking ActivatorUtilities.CreateInstance, but works fine if we define the constructors in reversed order:

public class Creatable
    {        
        public Creatable(
            A a,
            C c,
            S s)
        {
            WriteLine("Creatable.Short");
        }

        public Creatable(
            A a,
            B b,
            C c,
            S s)
        {
            WriteLine("Creatable.Long");
        }
    }

It's counter-intuitive, IMHO.

Additional findings

I've looked through the implementation and debugged it:

1. the first call to ConstructorMatcher.Match returns 0 (meaning that the constructor is the worst possible match, the constructor does not match our parameters at all);
2. the second call to ConstructorMatcher.Match returns 0, so it's not better than the first one and we dismiss it;
3. we create the instance with the best match we've found (even knowing that it is ambiguous and does not match the parameters at all).

Configuration

The issue is not specific to configuration.

Regression?

Does not seem to be a regression.

Other information

It's probably a corner case, but it still would be great to remove the undefined (as I understand it) behavior.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[quixoticaxis]

@GrabYourPitchforks sorry, isn't it area-Extensions-DependencyInjection? ActivatorUtilities comes from DependencyInjection.

[GrabYourPitchforks]

@quixoticaxis You're right - apologies!

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Current behavior

The effect of calling ActivatorUtilities.CreateInstance methods (any of the overloads) depends on the order in which the constructors of the type being created are defined. The instance of the class is created if constructors are defined in one order, but the creation throws if constructors are defined in reversed order (see the code below).

Expected behavior

The call throws because it failed to disambiguate the appropriate constructor. This behavior will be in-line with the behavior of Activator.CreateInstance.

Reproduction

using Microsoft.Extensions.DependencyInjection;

using static System.Console;

namespace AUCI
{
    public class A { }
    public class B { }
    public class C { }
    public class S { }

    public class Creatable
    {
        public Creatable(
            A a,
            B b,
            C c,
            S s)
        {
            WriteLine("Creatable.Long");
        }
        
        public Creatable(
            A a,
            C c,
            S s)
        {
            WriteLine("Creatable.Short");
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            var services = new ServiceCollection();
            services.AddScoped<S>();
            using var provider = services.BuildServiceProvider();

            var instance = ActivatorUtilities.CreateInstance(
                provider,
                typeof(Creatable),
                // Please, note that the order of parameters does not match the order of constructors' arguments
                new C(), new A()); 
        }       
    }
}

The code above throws when invoking ActivatorUtilities.CreateInstance, but works fine if we define the constructors in reversed order:

public class Creatable
    {        
        public Creatable(
            A a,
            C c,
            S s)
        {
            WriteLine("Creatable.Short");
        }

        public Creatable(
            A a,
            B b,
            C c,
            S s)
        {
            WriteLine("Creatable.Long");
        }
    }

It's counter-intuitive, IMHO.

Additional findings

I've looked through the implementation and debugged it:

1. the first call to ConstructorMatcher.Match returns 0 (meaning that the constructor is the worst possible match, the constructor does not match our parameters at all);
2. the second call to ConstructorMatcher.Match returns 0, so it's not better than the first one and we dismiss it;
3. we create the instance with the best match we've found (even knowing that it is ambiguous and does not match the parameters at all).

Configuration

The issue is not specific to configuration.

Regression?

Does not seem to be a regression.

Other information

It's probably a corner case, but it still would be great to remove the undefined (as I understand it) behavior.

Author:	quixoticaxis
Assignees:	-
Labels:	area-Extensions-DependencyInjection, untriaged
Milestone:	-

[KalleOlaviNiemitalo]

This may be what causes #45119.

It isn't clear to me how this should be fixed, though. If

• ActivatorUtilities is being asked to create an instance of class A with an IServiceProvider and no other arguments;
• class A has two constructors A(B, C) and A(D, E), neither of which has ActivatorUtilitiesConstructorAttribute;
• the IServiceProvider is able to create instances of B, D, and E, but not C;

then, I think it would be best if ActivatorUtilities selected the A(D, E) constructor and requested only instances of D and E from the IServiceProvider. However, IServiceProvider does not provide a way for ActivatorUtilities to ask whether it can provide B and C, without actually creating an instance of B. Thus, the IServiceProvider might have to create an instance of B, and perhaps instances of services required by B, even though ActivatorUtilities would be unable to use them in the end.

Perhaps that would not matter in practice.

[quixoticaxis]

@KalleOlaviNiemitalo I personally would prefer the call to fail in any case of ambiguity and make using an attribute a must for the case when the class has more than one constructor and CreateInstance is invoked without arguments. IMHO, it would make users' code more robust in the long run.

Also a separate method or an overload that takes Type[] constructorSignature can probably be introduced to cover the scenarios where the constructed class cannot be edited or when the user does not want to introduce the dependency on the attribute into the code.

[tarekgh]

I personally would prefer the call to fail in any case of ambiguity and make using an attribute a must for the case when the class has more than one constructor and CreateInstance is invoked without arguments.

There is no ambiguity here. what is happening is you are providing the class with the two constructors.

        public Creatable(A a, B b, C c,S s)
        public Creatable(A a, C c,S s)

It tries to find which constructor can be used to create the object when passing the parameters new C() and new A(). In checking the constructors, it finds both constructors having types for the whole list of the parameters. So, it detects both constructors can satisfy the operation and then select the first.

When having public Creatable(A a, B b, C c,S s) as the first constructor, it will use it and try to create the object using it. The problem with that is it cannot create instance of B parameter object and that is what is causing it to fail and throw the exception.
When having public Creatable(A a, C c,S s) as the first constructor, it succeeds because you supplied the a and c parameters, and s parameter can be created using the DI because you have registered it there.

The right fix here is when searching for suitable constructor to use to create the object, it should check if all parameters of such constructor can be created and choose it if it does. Otherwise, it shouldn't select this constructor. The only thing with this is, would be there any perf concern doing that? that is the part that need farther investigation. @davidfowl do you think the perf will matter much in such cases? to be more specific:

In the line

runtime/src/libraries/Microsoft.Extensions.DependencyInjection.Abstractions/src/ActivatorUtilities.cs

Line 63 in 2c8f2dc

bestMatcher = matcher;

before setting the best matcher, it should perform the following checks on all missing constructor parameters:

                        provider.GetService(_parameters[index].ParameterType) != null || 
                        ParameterDefaultValue.TryGetDefaultValue(_parameters[index], out object? defaultValue) // We may store the created object if needed so we don't have to recreate it again in `CreateInstance(IServiceProvider provider)`. or try not creating the parameter object at all.

[quixoticaxis]

@tarekgh Sorry, I probably don't understand something.

There is no ambiguity here. what is happening is you are providing the class with the two constructors.
…
So, it detects both constructors can satisfy the operation and then select the first.

You say that there is no ambiguity, then say that the code picks the first of the constructors. Is there any notion of constructor/member ordering in C#?
I've never seen any specification on member ordering, and while I can imagine it for classes defined in a single source file, I'm not certain what would be the "first constructor" for the partial class.