Type activator should be order agnostic

[mapogolions]

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

[ghost]

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

Issue Details

---

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

Author:	mapogolions
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[am11]

It is wasteful to construct an array, then only use its first element and throw away the rest. This block can be structured like this:

ConstructorInfo?constructorInfo=null;foreach(ConstructorInfo?ctorinctors){if(ctor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute))){if(constructorInfois not null){ThrowMultipleCtorsMarkedWithAttributeException();}constructorInfo=ctor;}}if(constructorInfois not null){ConstructorMatcherbestMatcher=new(constructorInfo);bestLength=bestMatcher.Match(parameters);if(bestLength==-1){ThrowMarkedCtorDoesNotTakeAllProvidedArguments();}}

This will also make using System.Linq; unnecessary.

[mapogolions]

@am11 Thanks for review. Good point

[am11]

Suggested change

	varmatcher=newConstructorMatcher(constructor);
	if(constructorisnull)
	{
	continue;
	}
	varmatcher=newConstructorMatcher(constructor);

[mapogolions]

@am11 What do you think if we just replace ConstructorInfo? with the ConstructorInfo in the foreach-loop foreach (ConstructorInfo?ConstructorInfo constructor in constructors)? According to documentation the GetConstructors() call should not return collection with nullable elements. https://docs.microsoft.com/en-us/dotnet/api/system.type.getconstructors?view=net-6.0#system-type-getconstructors

[am11]

Yes, makes sense. Based on the usage elsewhere in the repo, null is not checked. GetConstructor (singular), however, returns nullable object,

[eerhardt]

Thanks @mapogolions. Can you also ensure the scenarios listed in #46132 are addressed here as well?

Likewise, while we are fixing this bug, we should ensure the .NET Maui scenario is fixed as well, where the order of constructors looks like this:

publicLoginView(RandomItem item){//this is constructor is invoked by code and RandomItem is not registered in DI//therefore it should be skipped by ActivatorUtilities.CreateInstanceInitializeComponent();}// since there are no other valid constructors, ActivatorUtilities.CreateInstance should pick the default ctorpublicLoginView(){InitializeComponent();}

[mapogolions]

@eerhardt
Initially this PIR fixed this problem #42339
To fix this one #46132 need to a little bit tweak the algorithm for picking up the best constructor. In the last commits, I tried to do it. Please review. I don't know how the idea of fallback constructors will affect performance.

[eerhardt]

Thanks for getting this fix up @mapogolions. It looks like a great start.

FYI - @davidfowl@halter73@Tratcher - in case you want to take a look and have any feedback.

[eerhardt]

Thanks for adding this test. Can you also add one that ensures the default constructor is picked in this scenario?

dotnet/maui#4318 (comment)

Basically:

[Theory][InlineData(typeof(DefaultConstructorFirst)][InlineData(typeof(DefaultConstructorLast)]
public voidChoosesDefaultConstructorNoMatterOrder(TypeinstanceType){var services =newServiceCollection();usingvarprovider= services.BuildServiceProvider();var instance =ActivatorUtilities.CreateInstance(provider,instanceType);Assert.NotNull(instance);}public class DefaultConstructorFirst
{publicA A {get;}
public B B {get;}
public DefaultConstructorFirst(){}
public DefaultConstructorFirst(ClassAa){A=a;}
public DefaultConstructorFirst(ClassAa,ClassBb){A=a;B=b;}}
public classDefaultConstructorLast{
public A A {get;}
public B B {get;}
public DefaultConstructorLast(ClassAa,ClassBb){A=a;B=b;}
public DefaultConstructorLast(ClassAa){A=a;}
public DefaultConstructorLast(){}}

[eerhardt]

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintApplyExactLength{get;privateset;}=-1;

[eerhardt]

Maybe picking a better name here would help. How about

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintMatchedLength{get;privateset;}=-1;

[eerhardt]

The existing code passes false in for inherit. The new code uses a different overload that passes true for inherit. It's possible that this doesn't really matter for constructors, but I'd prefer to limit the changes to only what is necessary to fix the issue.

Suggested change

	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute)))
	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute),false))

[eerhardt]

I'm thinking about 2 optimizations here:

1. When there is only a single constructor, just use it.
2. When there are more than one, is there a way to not allocate an array here? Possibly we could stackalloc up to a reasonable count? Maybe 5 or 10? If the Type has more than that, then allocating an array seems OK since it won't be that common.

Maybe if we do (2), then special-casing (1) becomes unnecessary.

[eerhardt]

Might as well make the Match method return void since no one is consuming the return value anymore.

[Tratcher]

Prior related discussion: dotnet/aspnetcore#2871

[mapogolions]

@eerhardt
Thanks for feedback. Could you please review changes. As I understand from the comment above the ActivatorUtilities class should use the longest available constructor now. I've tried to address it. The new requirement breaks the following test case so I fixed it.

[eerhardt]

Why should B be null here? There is a scoped service for B, so shouldn't the ctor that takes a B be picked?

[mapogolions]

As I understand from dotnet/aspnetcore#2915, the longest available constructor should only be used if competing constructors
have the same priority/score (the value of the MatchedLength property reflects it)

Creatable class has two constructors

• Ctor(A a, B b, C c, S s)
• Ctor(A a, C c, S s) : this(a, null, c, s)

Let's look at the following 3 examples

1. ActivatorUtilities.CreateInstace(provider, new A(), new C());

According to the algorithm that was invented and used now and which I took as a basis, the first ctor is given score 1, the second one is given score 2 (2 given arguments match sequentially). As result the second constructor will be picked up (b is null)

2. ActivatorUtilities.CreateInstance(provider, new A())

The first ctor is given score 1, the second ctor is given score 1. We fall into a situation where we have competing constructors. In this case, the rule about the longest available constructor comes into play.

3. ActivatorUtilities.CreateInstance(provider, new C(), new A()) or ActivatorUtilities.CreateInstance(provider)
   Same as above, except for the fact that competing constructors are given score 0.

[eerhardt]

In the discussion in #46132, it is asking for an ambiguous exception to be thrown to be thrown in this case. Which seems like the right thing IMO. If there are multiple ctors that we can't really pick between, it is better to throw and say "use the ActivatorUtilitiesConstructorAttribute to disambiguate". It is really hard to define perfect behavior here when the "given arguments" and the "services available" can intermix.

See also all the discussion on #46132 for all the scenarios, and the intended behaviors.

[eerhardt]

@mapogolions - any thoughts on this?

[mapogolions]

@eerhardt I don't see a way to satisfy all the mentioned requirements (especially ambiguity detection). Feel free to close this as a dead end.

[eerhardt]

What about using the new (in 6.0) IServiceProviderIsService interface to test if a Type is available as a service in the IServiceProvider?

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

Lines 8 to 19 in b098b6f

	/// <summary>
	/// Optional service used to determine if the specified type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	publicinterfaceIServiceProviderIsService
	{
	/// <summary>
	/// Determines if the specified service type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	/// <param name="serviceType">An object that specifies the type of service object to test.</param>
	/// <returns>true if the specified service is a available, false if it is not.</returns>
	boolIsService(TypeserviceType);
	}

If the IServiceProvider doesn't support this new interface, then using the algorithm proposed here?

[eerhardt]

Closing as per #67493 (comment). Will either re-open or open a new PR to fix this issue.

[mapogolions]

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

[ghost]

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

Issue Details

---

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

Author:	mapogolions
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[am11]

It is wasteful to construct an array, then only use its first element and throw away the rest. This block can be structured like this:

ConstructorInfo?constructorInfo=null;foreach(ConstructorInfo?ctorinctors){if(ctor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute))){if(constructorInfois not null){ThrowMultipleCtorsMarkedWithAttributeException();}constructorInfo=ctor;}}if(constructorInfois not null){ConstructorMatcherbestMatcher=new(constructorInfo);bestLength=bestMatcher.Match(parameters);if(bestLength==-1){ThrowMarkedCtorDoesNotTakeAllProvidedArguments();}}

This will also make using System.Linq; unnecessary.

[mapogolions]

@am11 Thanks for review. Good point

[am11]

Suggested change

	varmatcher=newConstructorMatcher(constructor);
	if(constructorisnull)
	{
	continue;
	}
	varmatcher=newConstructorMatcher(constructor);

[mapogolions]

@am11 What do you think if we just replace ConstructorInfo? with the ConstructorInfo in the foreach-loop foreach (ConstructorInfo?ConstructorInfo constructor in constructors)? According to documentation the GetConstructors() call should not return collection with nullable elements. https://docs.microsoft.com/en-us/dotnet/api/system.type.getconstructors?view=net-6.0#system-type-getconstructors

[am11]

Yes, makes sense. Based on the usage elsewhere in the repo, null is not checked. GetConstructor (singular), however, returns nullable object,

[eerhardt]

Thanks @mapogolions. Can you also ensure the scenarios listed in #46132 are addressed here as well?

Likewise, while we are fixing this bug, we should ensure the .NET Maui scenario is fixed as well, where the order of constructors looks like this:

publicLoginView(RandomItem item){//this is constructor is invoked by code and RandomItem is not registered in DI//therefore it should be skipped by ActivatorUtilities.CreateInstanceInitializeComponent();}// since there are no other valid constructors, ActivatorUtilities.CreateInstance should pick the default ctorpublicLoginView(){InitializeComponent();}

[mapogolions]

@eerhardt
Initially this PIR fixed this problem #42339
To fix this one #46132 need to a little bit tweak the algorithm for picking up the best constructor. In the last commits, I tried to do it. Please review. I don't know how the idea of fallback constructors will affect performance.

[eerhardt]

Thanks for getting this fix up @mapogolions. It looks like a great start.

FYI - @davidfowl@halter73@Tratcher - in case you want to take a look and have any feedback.

[eerhardt]

Thanks for adding this test. Can you also add one that ensures the default constructor is picked in this scenario?

dotnet/maui#4318 (comment)

Basically:

[Theory][InlineData(typeof(DefaultConstructorFirst)][InlineData(typeof(DefaultConstructorLast)]
public voidChoosesDefaultConstructorNoMatterOrder(TypeinstanceType){var services =newServiceCollection();usingvarprovider= services.BuildServiceProvider();var instance =ActivatorUtilities.CreateInstance(provider,instanceType);Assert.NotNull(instance);}public class DefaultConstructorFirst
{publicA A {get;}
public B B {get;}
public DefaultConstructorFirst(){}
public DefaultConstructorFirst(ClassAa){A=a;}
public DefaultConstructorFirst(ClassAa,ClassBb){A=a;B=b;}}
public classDefaultConstructorLast{
public A A {get;}
public B B {get;}
public DefaultConstructorLast(ClassAa,ClassBb){A=a;B=b;}
public DefaultConstructorLast(ClassAa){A=a;}
public DefaultConstructorLast(){}}

[eerhardt]

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintApplyExactLength{get;privateset;}=-1;

[eerhardt]

Maybe picking a better name here would help. How about

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintMatchedLength{get;privateset;}=-1;

[eerhardt]

The existing code passes false in for inherit. The new code uses a different overload that passes true for inherit. It's possible that this doesn't really matter for constructors, but I'd prefer to limit the changes to only what is necessary to fix the issue.

Suggested change

	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute)))
	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute),false))

[eerhardt]

I'm thinking about 2 optimizations here:

1. When there is only a single constructor, just use it.
2. When there are more than one, is there a way to not allocate an array here? Possibly we could stackalloc up to a reasonable count? Maybe 5 or 10? If the Type has more than that, then allocating an array seems OK since it won't be that common.

Maybe if we do (2), then special-casing (1) becomes unnecessary.

[eerhardt]

Might as well make the Match method return void since no one is consuming the return value anymore.

[Tratcher]

Prior related discussion: dotnet/aspnetcore#2871

[mapogolions]

@eerhardt
Thanks for feedback. Could you please review changes. As I understand from the comment above the ActivatorUtilities class should use the longest available constructor now. I've tried to address it. The new requirement breaks the following test case so I fixed it.

[eerhardt]

Why should B be null here? There is a scoped service for B, so shouldn't the ctor that takes a B be picked?

[mapogolions]

As I understand from dotnet/aspnetcore#2915, the longest available constructor should only be used if competing constructors
have the same priority/score (the value of the MatchedLength property reflects it)

Creatable class has two constructors

• Ctor(A a, B b, C c, S s)
• Ctor(A a, C c, S s) : this(a, null, c, s)

Let's look at the following 3 examples

1. ActivatorUtilities.CreateInstace(provider, new A(), new C());

According to the algorithm that was invented and used now and which I took as a basis, the first ctor is given score 1, the second one is given score 2 (2 given arguments match sequentially). As result the second constructor will be picked up (b is null)

2. ActivatorUtilities.CreateInstance(provider, new A())

The first ctor is given score 1, the second ctor is given score 1. We fall into a situation where we have competing constructors. In this case, the rule about the longest available constructor comes into play.

3. ActivatorUtilities.CreateInstance(provider, new C(), new A()) or ActivatorUtilities.CreateInstance(provider)
   Same as above, except for the fact that competing constructors are given score 0.

[eerhardt]

In the discussion in #46132, it is asking for an ambiguous exception to be thrown to be thrown in this case. Which seems like the right thing IMO. If there are multiple ctors that we can't really pick between, it is better to throw and say "use the ActivatorUtilitiesConstructorAttribute to disambiguate". It is really hard to define perfect behavior here when the "given arguments" and the "services available" can intermix.

See also all the discussion on #46132 for all the scenarios, and the intended behaviors.

[eerhardt]

@mapogolions - any thoughts on this?

[mapogolions]

@eerhardt I don't see a way to satisfy all the mentioned requirements (especially ambiguity detection). Feel free to close this as a dead end.

[eerhardt]

What about using the new (in 6.0) IServiceProviderIsService interface to test if a Type is available as a service in the IServiceProvider?

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

Lines 8 to 19 in b098b6f

	/// <summary>
	/// Optional service used to determine if the specified type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	publicinterfaceIServiceProviderIsService
	{
	/// <summary>
	/// Determines if the specified service type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	/// <param name="serviceType">An object that specifies the type of service object to test.</param>
	/// <returns>true if the specified service is a available, false if it is not.</returns>
	boolIsService(TypeserviceType);
	}

If the IServiceProvider doesn't support this new interface, then using the algorithm proposed here?

[eerhardt]

Closing as per #67493 (comment). Will either re-open or open a new PR to fix this issue.

[mapogolions]

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

[ghost]

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

Issue Details

---

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

Author:	mapogolions
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[am11]

It is wasteful to construct an array, then only use its first element and throw away the rest. This block can be structured like this:

ConstructorInfo?constructorInfo=null;foreach(ConstructorInfo?ctorinctors){if(ctor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute))){if(constructorInfois not null){ThrowMultipleCtorsMarkedWithAttributeException();}constructorInfo=ctor;}}if(constructorInfois not null){ConstructorMatcherbestMatcher=new(constructorInfo);bestLength=bestMatcher.Match(parameters);if(bestLength==-1){ThrowMarkedCtorDoesNotTakeAllProvidedArguments();}}

This will also make using System.Linq; unnecessary.

[mapogolions]

@am11 Thanks for review. Good point

[am11]

Suggested change

	varmatcher=newConstructorMatcher(constructor);
	if(constructorisnull)
	{
	continue;
	}
	varmatcher=newConstructorMatcher(constructor);

[mapogolions]

@am11 What do you think if we just replace ConstructorInfo? with the ConstructorInfo in the foreach-loop foreach (ConstructorInfo?ConstructorInfo constructor in constructors)? According to documentation the GetConstructors() call should not return collection with nullable elements. https://docs.microsoft.com/en-us/dotnet/api/system.type.getconstructors?view=net-6.0#system-type-getconstructors

[am11]

Yes, makes sense. Based on the usage elsewhere in the repo, null is not checked. GetConstructor (singular), however, returns nullable object,

[eerhardt]

Thanks @mapogolions. Can you also ensure the scenarios listed in #46132 are addressed here as well?

Likewise, while we are fixing this bug, we should ensure the .NET Maui scenario is fixed as well, where the order of constructors looks like this:

publicLoginView(RandomItem item){//this is constructor is invoked by code and RandomItem is not registered in DI//therefore it should be skipped by ActivatorUtilities.CreateInstanceInitializeComponent();}// since there are no other valid constructors, ActivatorUtilities.CreateInstance should pick the default ctorpublicLoginView(){InitializeComponent();}

[mapogolions]

@eerhardt
Initially this PIR fixed this problem #42339
To fix this one #46132 need to a little bit tweak the algorithm for picking up the best constructor. In the last commits, I tried to do it. Please review. I don't know how the idea of fallback constructors will affect performance.

[eerhardt]

Thanks for getting this fix up @mapogolions. It looks like a great start.

FYI - @davidfowl@halter73@Tratcher - in case you want to take a look and have any feedback.

[eerhardt]

Thanks for adding this test. Can you also add one that ensures the default constructor is picked in this scenario?

dotnet/maui#4318 (comment)

Basically:

[Theory][InlineData(typeof(DefaultConstructorFirst)][InlineData(typeof(DefaultConstructorLast)]
public voidChoosesDefaultConstructorNoMatterOrder(TypeinstanceType){var services =newServiceCollection();usingvarprovider= services.BuildServiceProvider();var instance =ActivatorUtilities.CreateInstance(provider,instanceType);Assert.NotNull(instance);}public class DefaultConstructorFirst
{publicA A {get;}
public B B {get;}
public DefaultConstructorFirst(){}
public DefaultConstructorFirst(ClassAa){A=a;}
public DefaultConstructorFirst(ClassAa,ClassBb){A=a;B=b;}}
public classDefaultConstructorLast{
public A A {get;}
public B B {get;}
public DefaultConstructorLast(ClassAa,ClassBb){A=a;B=b;}
public DefaultConstructorLast(ClassAa){A=a;}
public DefaultConstructorLast(){}}

[eerhardt]

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintApplyExactLength{get;privateset;}=-1;

[eerhardt]

Maybe picking a better name here would help. How about

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintMatchedLength{get;privateset;}=-1;

[eerhardt]

The existing code passes false in for inherit. The new code uses a different overload that passes true for inherit. It's possible that this doesn't really matter for constructors, but I'd prefer to limit the changes to only what is necessary to fix the issue.

Suggested change

	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute)))
	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute),false))

[eerhardt]

I'm thinking about 2 optimizations here:

1. When there is only a single constructor, just use it.
2. When there are more than one, is there a way to not allocate an array here? Possibly we could stackalloc up to a reasonable count? Maybe 5 or 10? If the Type has more than that, then allocating an array seems OK since it won't be that common.

Maybe if we do (2), then special-casing (1) becomes unnecessary.

[eerhardt]

Might as well make the Match method return void since no one is consuming the return value anymore.

[Tratcher]

Prior related discussion: dotnet/aspnetcore#2871

[mapogolions]

@eerhardt
Thanks for feedback. Could you please review changes. As I understand from the comment above the ActivatorUtilities class should use the longest available constructor now. I've tried to address it. The new requirement breaks the following test case so I fixed it.

[eerhardt]

Why should B be null here? There is a scoped service for B, so shouldn't the ctor that takes a B be picked?

[mapogolions]

As I understand from dotnet/aspnetcore#2915, the longest available constructor should only be used if competing constructors
have the same priority/score (the value of the MatchedLength property reflects it)

Creatable class has two constructors

• Ctor(A a, B b, C c, S s)
• Ctor(A a, C c, S s) : this(a, null, c, s)

Let's look at the following 3 examples

1. ActivatorUtilities.CreateInstace(provider, new A(), new C());

According to the algorithm that was invented and used now and which I took as a basis, the first ctor is given score 1, the second one is given score 2 (2 given arguments match sequentially). As result the second constructor will be picked up (b is null)

2. ActivatorUtilities.CreateInstance(provider, new A())

The first ctor is given score 1, the second ctor is given score 1. We fall into a situation where we have competing constructors. In this case, the rule about the longest available constructor comes into play.

3. ActivatorUtilities.CreateInstance(provider, new C(), new A()) or ActivatorUtilities.CreateInstance(provider)
   Same as above, except for the fact that competing constructors are given score 0.

[eerhardt]

In the discussion in #46132, it is asking for an ambiguous exception to be thrown to be thrown in this case. Which seems like the right thing IMO. If there are multiple ctors that we can't really pick between, it is better to throw and say "use the ActivatorUtilitiesConstructorAttribute to disambiguate". It is really hard to define perfect behavior here when the "given arguments" and the "services available" can intermix.

See also all the discussion on #46132 for all the scenarios, and the intended behaviors.

[eerhardt]

@mapogolions - any thoughts on this?

[mapogolions]

@eerhardt I don't see a way to satisfy all the mentioned requirements (especially ambiguity detection). Feel free to close this as a dead end.

[eerhardt]

What about using the new (in 6.0) IServiceProviderIsService interface to test if a Type is available as a service in the IServiceProvider?

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

Lines 8 to 19 in b098b6f

	/// <summary>
	/// Optional service used to determine if the specified type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	publicinterfaceIServiceProviderIsService
	{
	/// <summary>
	/// Determines if the specified service type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	/// <param name="serviceType">An object that specifies the type of service object to test.</param>
	/// <returns>true if the specified service is a available, false if it is not.</returns>
	boolIsService(TypeserviceType);
	}

If the IServiceProvider doesn't support this new interface, then using the algorithm proposed here?

[eerhardt]

Closing as per #67493 (comment). Will either re-open or open a new PR to fix this issue.

[mapogolions]

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

[ghost]

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

Issue Details

---

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

Author:	mapogolions
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[am11]

It is wasteful to construct an array, then only use its first element and throw away the rest. This block can be structured like this:

ConstructorInfo?constructorInfo=null;foreach(ConstructorInfo?ctorinctors){if(ctor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute))){if(constructorInfois not null){ThrowMultipleCtorsMarkedWithAttributeException();}constructorInfo=ctor;}}if(constructorInfois not null){ConstructorMatcherbestMatcher=new(constructorInfo);bestLength=bestMatcher.Match(parameters);if(bestLength==-1){ThrowMarkedCtorDoesNotTakeAllProvidedArguments();}}

This will also make using System.Linq; unnecessary.

[mapogolions]

@am11 Thanks for review. Good point

[am11]

Suggested change

	varmatcher=newConstructorMatcher(constructor);
	if(constructorisnull)
	{
	continue;
	}
	varmatcher=newConstructorMatcher(constructor);

[mapogolions]

@am11 What do you think if we just replace ConstructorInfo? with the ConstructorInfo in the foreach-loop foreach (ConstructorInfo?ConstructorInfo constructor in constructors)? According to documentation the GetConstructors() call should not return collection with nullable elements. https://docs.microsoft.com/en-us/dotnet/api/system.type.getconstructors?view=net-6.0#system-type-getconstructors

[am11]

Yes, makes sense. Based on the usage elsewhere in the repo, null is not checked. GetConstructor (singular), however, returns nullable object,

[eerhardt]

Thanks @mapogolions. Can you also ensure the scenarios listed in #46132 are addressed here as well?

Likewise, while we are fixing this bug, we should ensure the .NET Maui scenario is fixed as well, where the order of constructors looks like this:

publicLoginView(RandomItem item){//this is constructor is invoked by code and RandomItem is not registered in DI//therefore it should be skipped by ActivatorUtilities.CreateInstanceInitializeComponent();}// since there are no other valid constructors, ActivatorUtilities.CreateInstance should pick the default ctorpublicLoginView(){InitializeComponent();}

[mapogolions]

@eerhardt
Initially this PIR fixed this problem #42339
To fix this one #46132 need to a little bit tweak the algorithm for picking up the best constructor. In the last commits, I tried to do it. Please review. I don't know how the idea of fallback constructors will affect performance.

[eerhardt]

Thanks for getting this fix up @mapogolions. It looks like a great start.

FYI - @davidfowl@halter73@Tratcher - in case you want to take a look and have any feedback.

[eerhardt]

Thanks for adding this test. Can you also add one that ensures the default constructor is picked in this scenario?

dotnet/maui#4318 (comment)

Basically:

[Theory][InlineData(typeof(DefaultConstructorFirst)][InlineData(typeof(DefaultConstructorLast)]
public voidChoosesDefaultConstructorNoMatterOrder(TypeinstanceType){var services =newServiceCollection();usingvarprovider= services.BuildServiceProvider();var instance =ActivatorUtilities.CreateInstance(provider,instanceType);Assert.NotNull(instance);}public class DefaultConstructorFirst
{publicA A {get;}
public B B {get;}
public DefaultConstructorFirst(){}
public DefaultConstructorFirst(ClassAa){A=a;}
public DefaultConstructorFirst(ClassAa,ClassBb){A=a;B=b;}}
public classDefaultConstructorLast{
public A A {get;}
public B B {get;}
public DefaultConstructorLast(ClassAa,ClassBb){A=a;B=b;}
public DefaultConstructorLast(ClassAa){A=a;}
public DefaultConstructorLast(){}}

[eerhardt]

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintApplyExactLength{get;privateset;}=-1;

[eerhardt]

Maybe picking a better name here would help. How about

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintMatchedLength{get;privateset;}=-1;

[eerhardt]

The existing code passes false in for inherit. The new code uses a different overload that passes true for inherit. It's possible that this doesn't really matter for constructors, but I'd prefer to limit the changes to only what is necessary to fix the issue.

Suggested change

	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute)))
	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute),false))

[eerhardt]

I'm thinking about 2 optimizations here:

1. When there is only a single constructor, just use it.
2. When there are more than one, is there a way to not allocate an array here? Possibly we could stackalloc up to a reasonable count? Maybe 5 or 10? If the Type has more than that, then allocating an array seems OK since it won't be that common.

Maybe if we do (2), then special-casing (1) becomes unnecessary.

[eerhardt]

Might as well make the Match method return void since no one is consuming the return value anymore.

[Tratcher]

Prior related discussion: dotnet/aspnetcore#2871

[mapogolions]

@eerhardt
Thanks for feedback. Could you please review changes. As I understand from the comment above the ActivatorUtilities class should use the longest available constructor now. I've tried to address it. The new requirement breaks the following test case so I fixed it.

[eerhardt]

Why should B be null here? There is a scoped service for B, so shouldn't the ctor that takes a B be picked?

[mapogolions]

As I understand from dotnet/aspnetcore#2915, the longest available constructor should only be used if competing constructors
have the same priority/score (the value of the MatchedLength property reflects it)

Creatable class has two constructors

• Ctor(A a, B b, C c, S s)
• Ctor(A a, C c, S s) : this(a, null, c, s)

Let's look at the following 3 examples

1. ActivatorUtilities.CreateInstace(provider, new A(), new C());

According to the algorithm that was invented and used now and which I took as a basis, the first ctor is given score 1, the second one is given score 2 (2 given arguments match sequentially). As result the second constructor will be picked up (b is null)

2. ActivatorUtilities.CreateInstance(provider, new A())

The first ctor is given score 1, the second ctor is given score 1. We fall into a situation where we have competing constructors. In this case, the rule about the longest available constructor comes into play.

3. ActivatorUtilities.CreateInstance(provider, new C(), new A()) or ActivatorUtilities.CreateInstance(provider)
   Same as above, except for the fact that competing constructors are given score 0.

[eerhardt]

In the discussion in #46132, it is asking for an ambiguous exception to be thrown to be thrown in this case. Which seems like the right thing IMO. If there are multiple ctors that we can't really pick between, it is better to throw and say "use the ActivatorUtilitiesConstructorAttribute to disambiguate". It is really hard to define perfect behavior here when the "given arguments" and the "services available" can intermix.

See also all the discussion on #46132 for all the scenarios, and the intended behaviors.

[eerhardt]

@mapogolions - any thoughts on this?

[mapogolions]

@eerhardt I don't see a way to satisfy all the mentioned requirements (especially ambiguity detection). Feel free to close this as a dead end.

[eerhardt]

What about using the new (in 6.0) IServiceProviderIsService interface to test if a Type is available as a service in the IServiceProvider?

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

Lines 8 to 19 in b098b6f

	/// <summary>
	/// Optional service used to determine if the specified type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	publicinterfaceIServiceProviderIsService
	{
	/// <summary>
	/// Determines if the specified service type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	/// <param name="serviceType">An object that specifies the type of service object to test.</param>
	/// <returns>true if the specified service is a available, false if it is not.</returns>
	boolIsService(TypeserviceType);
	}

If the IServiceProvider doesn't support this new interface, then using the algorithm proposed here?

[eerhardt]

Closing as per #67493 (comment). Will either re-open or open a new PR to fix this issue.

[mapogolions]

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

[ghost]

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

Issue Details

---

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

Author:	mapogolions
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[am11]

It is wasteful to construct an array, then only use its first element and throw away the rest. This block can be structured like this:

ConstructorInfo?constructorInfo=null;foreach(ConstructorInfo?ctorinctors){if(ctor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute))){if(constructorInfois not null){ThrowMultipleCtorsMarkedWithAttributeException();}constructorInfo=ctor;}}if(constructorInfois not null){ConstructorMatcherbestMatcher=new(constructorInfo);bestLength=bestMatcher.Match(parameters);if(bestLength==-1){ThrowMarkedCtorDoesNotTakeAllProvidedArguments();}}

This will also make using System.Linq; unnecessary.

[mapogolions]

@am11 Thanks for review. Good point

[am11]

Suggested change

	varmatcher=newConstructorMatcher(constructor);
	if(constructorisnull)
	{
	continue;
	}
	varmatcher=newConstructorMatcher(constructor);

[mapogolions]

@am11 What do you think if we just replace ConstructorInfo? with the ConstructorInfo in the foreach-loop foreach (ConstructorInfo?ConstructorInfo constructor in constructors)? According to documentation the GetConstructors() call should not return collection with nullable elements. https://docs.microsoft.com/en-us/dotnet/api/system.type.getconstructors?view=net-6.0#system-type-getconstructors

[am11]

Yes, makes sense. Based on the usage elsewhere in the repo, null is not checked. GetConstructor (singular), however, returns nullable object,

[eerhardt]

Thanks @mapogolions. Can you also ensure the scenarios listed in #46132 are addressed here as well?

Likewise, while we are fixing this bug, we should ensure the .NET Maui scenario is fixed as well, where the order of constructors looks like this:

publicLoginView(RandomItem item){//this is constructor is invoked by code and RandomItem is not registered in DI//therefore it should be skipped by ActivatorUtilities.CreateInstanceInitializeComponent();}// since there are no other valid constructors, ActivatorUtilities.CreateInstance should pick the default ctorpublicLoginView(){InitializeComponent();}

[mapogolions]

@eerhardt
Initially this PIR fixed this problem #42339
To fix this one #46132 need to a little bit tweak the algorithm for picking up the best constructor. In the last commits, I tried to do it. Please review. I don't know how the idea of fallback constructors will affect performance.

[eerhardt]

Thanks for getting this fix up @mapogolions. It looks like a great start.

FYI - @davidfowl@halter73@Tratcher - in case you want to take a look and have any feedback.

[eerhardt]

Thanks for adding this test. Can you also add one that ensures the default constructor is picked in this scenario?

dotnet/maui#4318 (comment)

Basically:

[Theory][InlineData(typeof(DefaultConstructorFirst)][InlineData(typeof(DefaultConstructorLast)]
public voidChoosesDefaultConstructorNoMatterOrder(TypeinstanceType){var services =newServiceCollection();usingvarprovider= services.BuildServiceProvider();var instance =ActivatorUtilities.CreateInstance(provider,instanceType);Assert.NotNull(instance);}public class DefaultConstructorFirst
{publicA A {get;}
public B B {get;}
public DefaultConstructorFirst(){}
public DefaultConstructorFirst(ClassAa){A=a;}
public DefaultConstructorFirst(ClassAa,ClassBb){A=a;B=b;}}
public classDefaultConstructorLast{
public A A {get;}
public B B {get;}
public DefaultConstructorLast(ClassAa,ClassBb){A=a;B=b;}
public DefaultConstructorLast(ClassAa){A=a;}
public DefaultConstructorLast(){}}

[eerhardt]

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintApplyExactLength{get;privateset;}=-1;

[eerhardt]

Maybe picking a better name here would help. How about

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintMatchedLength{get;privateset;}=-1;

[eerhardt]

The existing code passes false in for inherit. The new code uses a different overload that passes true for inherit. It's possible that this doesn't really matter for constructors, but I'd prefer to limit the changes to only what is necessary to fix the issue.

Suggested change

	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute)))
	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute),false))

[eerhardt]

I'm thinking about 2 optimizations here:

1. When there is only a single constructor, just use it.
2. When there are more than one, is there a way to not allocate an array here? Possibly we could stackalloc up to a reasonable count? Maybe 5 or 10? If the Type has more than that, then allocating an array seems OK since it won't be that common.

Maybe if we do (2), then special-casing (1) becomes unnecessary.

[eerhardt]

Might as well make the Match method return void since no one is consuming the return value anymore.

[Tratcher]

Prior related discussion: dotnet/aspnetcore#2871

[mapogolions]

@eerhardt
Thanks for feedback. Could you please review changes. As I understand from the comment above the ActivatorUtilities class should use the longest available constructor now. I've tried to address it. The new requirement breaks the following test case so I fixed it.

[eerhardt]

Why should B be null here? There is a scoped service for B, so shouldn't the ctor that takes a B be picked?

[mapogolions]

As I understand from dotnet/aspnetcore#2915, the longest available constructor should only be used if competing constructors
have the same priority/score (the value of the MatchedLength property reflects it)

Creatable class has two constructors

• Ctor(A a, B b, C c, S s)
• Ctor(A a, C c, S s) : this(a, null, c, s)

Let's look at the following 3 examples

1. ActivatorUtilities.CreateInstace(provider, new A(), new C());

According to the algorithm that was invented and used now and which I took as a basis, the first ctor is given score 1, the second one is given score 2 (2 given arguments match sequentially). As result the second constructor will be picked up (b is null)

2. ActivatorUtilities.CreateInstance(provider, new A())

The first ctor is given score 1, the second ctor is given score 1. We fall into a situation where we have competing constructors. In this case, the rule about the longest available constructor comes into play.

3. ActivatorUtilities.CreateInstance(provider, new C(), new A()) or ActivatorUtilities.CreateInstance(provider)
   Same as above, except for the fact that competing constructors are given score 0.

[eerhardt]

In the discussion in #46132, it is asking for an ambiguous exception to be thrown to be thrown in this case. Which seems like the right thing IMO. If there are multiple ctors that we can't really pick between, it is better to throw and say "use the ActivatorUtilitiesConstructorAttribute to disambiguate". It is really hard to define perfect behavior here when the "given arguments" and the "services available" can intermix.

See also all the discussion on #46132 for all the scenarios, and the intended behaviors.

[eerhardt]

@mapogolions - any thoughts on this?

[mapogolions]

@eerhardt I don't see a way to satisfy all the mentioned requirements (especially ambiguity detection). Feel free to close this as a dead end.

[eerhardt]

What about using the new (in 6.0) IServiceProviderIsService interface to test if a Type is available as a service in the IServiceProvider?

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

Lines 8 to 19 in b098b6f

	/// <summary>
	/// Optional service used to determine if the specified type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	publicinterfaceIServiceProviderIsService
	{
	/// <summary>
	/// Determines if the specified service type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	/// <param name="serviceType">An object that specifies the type of service object to test.</param>
	/// <returns>true if the specified service is a available, false if it is not.</returns>
	boolIsService(TypeserviceType);
	}

If the IServiceProvider doesn't support this new interface, then using the algorithm proposed here?

[eerhardt]

Closing as per #67493 (comment). Will either re-open or open a new PR to fix this issue.

[mapogolions]

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

[ghost]

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

Issue Details

---

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

Author:	mapogolions
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[am11]

It is wasteful to construct an array, then only use its first element and throw away the rest. This block can be structured like this:

ConstructorInfo?constructorInfo=null;foreach(ConstructorInfo?ctorinctors){if(ctor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute))){if(constructorInfois not null){ThrowMultipleCtorsMarkedWithAttributeException();}constructorInfo=ctor;}}if(constructorInfois not null){ConstructorMatcherbestMatcher=new(constructorInfo);bestLength=bestMatcher.Match(parameters);if(bestLength==-1){ThrowMarkedCtorDoesNotTakeAllProvidedArguments();}}

This will also make using System.Linq; unnecessary.

[mapogolions]

@am11 Thanks for review. Good point

[am11]

Suggested change

	varmatcher=newConstructorMatcher(constructor);
	if(constructorisnull)
	{
	continue;
	}
	varmatcher=newConstructorMatcher(constructor);

[mapogolions]

@am11 What do you think if we just replace ConstructorInfo? with the ConstructorInfo in the foreach-loop foreach (ConstructorInfo?ConstructorInfo constructor in constructors)? According to documentation the GetConstructors() call should not return collection with nullable elements. https://docs.microsoft.com/en-us/dotnet/api/system.type.getconstructors?view=net-6.0#system-type-getconstructors

[am11]

Yes, makes sense. Based on the usage elsewhere in the repo, null is not checked. GetConstructor (singular), however, returns nullable object,

[eerhardt]

Thanks @mapogolions. Can you also ensure the scenarios listed in #46132 are addressed here as well?

Likewise, while we are fixing this bug, we should ensure the .NET Maui scenario is fixed as well, where the order of constructors looks like this:

publicLoginView(RandomItem item){//this is constructor is invoked by code and RandomItem is not registered in DI//therefore it should be skipped by ActivatorUtilities.CreateInstanceInitializeComponent();}// since there are no other valid constructors, ActivatorUtilities.CreateInstance should pick the default ctorpublicLoginView(){InitializeComponent();}

[mapogolions]

@eerhardt
Initially this PIR fixed this problem #42339
To fix this one #46132 need to a little bit tweak the algorithm for picking up the best constructor. In the last commits, I tried to do it. Please review. I don't know how the idea of fallback constructors will affect performance.

[eerhardt]

Thanks for getting this fix up @mapogolions. It looks like a great start.

FYI - @davidfowl@halter73@Tratcher - in case you want to take a look and have any feedback.

[eerhardt]

Thanks for adding this test. Can you also add one that ensures the default constructor is picked in this scenario?

dotnet/maui#4318 (comment)

Basically:

[Theory][InlineData(typeof(DefaultConstructorFirst)][InlineData(typeof(DefaultConstructorLast)]
public voidChoosesDefaultConstructorNoMatterOrder(TypeinstanceType){var services =newServiceCollection();usingvarprovider= services.BuildServiceProvider();var instance =ActivatorUtilities.CreateInstance(provider,instanceType);Assert.NotNull(instance);}public class DefaultConstructorFirst
{publicA A {get;}
public B B {get;}
public DefaultConstructorFirst(){}
public DefaultConstructorFirst(ClassAa){A=a;}
public DefaultConstructorFirst(ClassAa,ClassBb){A=a;B=b;}}
public classDefaultConstructorLast{
public A A {get;}
public B B {get;}
public DefaultConstructorLast(ClassAa,ClassBb){A=a;B=b;}
public DefaultConstructorLast(ClassAa){A=a;}
public DefaultConstructorLast(){}}

[eerhardt]

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintApplyExactLength{get;privateset;}=-1;

[eerhardt]

Maybe picking a better name here would help. How about

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintMatchedLength{get;privateset;}=-1;

[eerhardt]

The existing code passes false in for inherit. The new code uses a different overload that passes true for inherit. It's possible that this doesn't really matter for constructors, but I'd prefer to limit the changes to only what is necessary to fix the issue.

Suggested change

	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute)))
	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute),false))

[eerhardt]

I'm thinking about 2 optimizations here:

1. When there is only a single constructor, just use it.
2. When there are more than one, is there a way to not allocate an array here? Possibly we could stackalloc up to a reasonable count? Maybe 5 or 10? If the Type has more than that, then allocating an array seems OK since it won't be that common.

Maybe if we do (2), then special-casing (1) becomes unnecessary.

[eerhardt]

Might as well make the Match method return void since no one is consuming the return value anymore.

[Tratcher]

Prior related discussion: dotnet/aspnetcore#2871

[mapogolions]

@eerhardt
Thanks for feedback. Could you please review changes. As I understand from the comment above the ActivatorUtilities class should use the longest available constructor now. I've tried to address it. The new requirement breaks the following test case so I fixed it.

[eerhardt]

Why should B be null here? There is a scoped service for B, so shouldn't the ctor that takes a B be picked?

[mapogolions]

As I understand from dotnet/aspnetcore#2915, the longest available constructor should only be used if competing constructors
have the same priority/score (the value of the MatchedLength property reflects it)

Creatable class has two constructors

• Ctor(A a, B b, C c, S s)
• Ctor(A a, C c, S s) : this(a, null, c, s)

Let's look at the following 3 examples

1. ActivatorUtilities.CreateInstace(provider, new A(), new C());

According to the algorithm that was invented and used now and which I took as a basis, the first ctor is given score 1, the second one is given score 2 (2 given arguments match sequentially). As result the second constructor will be picked up (b is null)

2. ActivatorUtilities.CreateInstance(provider, new A())

The first ctor is given score 1, the second ctor is given score 1. We fall into a situation where we have competing constructors. In this case, the rule about the longest available constructor comes into play.

3. ActivatorUtilities.CreateInstance(provider, new C(), new A()) or ActivatorUtilities.CreateInstance(provider)
   Same as above, except for the fact that competing constructors are given score 0.

[eerhardt]

In the discussion in #46132, it is asking for an ambiguous exception to be thrown to be thrown in this case. Which seems like the right thing IMO. If there are multiple ctors that we can't really pick between, it is better to throw and say "use the ActivatorUtilitiesConstructorAttribute to disambiguate". It is really hard to define perfect behavior here when the "given arguments" and the "services available" can intermix.

See also all the discussion on #46132 for all the scenarios, and the intended behaviors.

[eerhardt]

@mapogolions - any thoughts on this?

[mapogolions]

@eerhardt I don't see a way to satisfy all the mentioned requirements (especially ambiguity detection). Feel free to close this as a dead end.

[eerhardt]

What about using the new (in 6.0) IServiceProviderIsService interface to test if a Type is available as a service in the IServiceProvider?

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

Lines 8 to 19 in b098b6f

	/// <summary>
	/// Optional service used to determine if the specified type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	publicinterfaceIServiceProviderIsService
	{
	/// <summary>
	/// Determines if the specified service type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	/// <param name="serviceType">An object that specifies the type of service object to test.</param>
	/// <returns>true if the specified service is a available, false if it is not.</returns>
	boolIsService(TypeserviceType);
	}

If the IServiceProvider doesn't support this new interface, then using the algorithm proposed here?

[eerhardt]

Closing as per #67493 (comment). Will either re-open or open a new PR to fix this issue.

[mapogolions]

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

[ghost]

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

Issue Details

---

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

Author:	mapogolions
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[am11]

It is wasteful to construct an array, then only use its first element and throw away the rest. This block can be structured like this:

ConstructorInfo?constructorInfo=null;foreach(ConstructorInfo?ctorinctors){if(ctor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute))){if(constructorInfois not null){ThrowMultipleCtorsMarkedWithAttributeException();}constructorInfo=ctor;}}if(constructorInfois not null){ConstructorMatcherbestMatcher=new(constructorInfo);bestLength=bestMatcher.Match(parameters);if(bestLength==-1){ThrowMarkedCtorDoesNotTakeAllProvidedArguments();}}

This will also make using System.Linq; unnecessary.

[mapogolions]

@am11 Thanks for review. Good point

[am11]

Suggested change

	varmatcher=newConstructorMatcher(constructor);
	if(constructorisnull)
	{
	continue;
	}
	varmatcher=newConstructorMatcher(constructor);

[mapogolions]

@am11 What do you think if we just replace ConstructorInfo? with the ConstructorInfo in the foreach-loop foreach (ConstructorInfo?ConstructorInfo constructor in constructors)? According to documentation the GetConstructors() call should not return collection with nullable elements. https://docs.microsoft.com/en-us/dotnet/api/system.type.getconstructors?view=net-6.0#system-type-getconstructors

[am11]

Yes, makes sense. Based on the usage elsewhere in the repo, null is not checked. GetConstructor (singular), however, returns nullable object,

[eerhardt]

Thanks @mapogolions. Can you also ensure the scenarios listed in #46132 are addressed here as well?

Likewise, while we are fixing this bug, we should ensure the .NET Maui scenario is fixed as well, where the order of constructors looks like this:

publicLoginView(RandomItem item){//this is constructor is invoked by code and RandomItem is not registered in DI//therefore it should be skipped by ActivatorUtilities.CreateInstanceInitializeComponent();}// since there are no other valid constructors, ActivatorUtilities.CreateInstance should pick the default ctorpublicLoginView(){InitializeComponent();}

[mapogolions]

@eerhardt
Initially this PIR fixed this problem #42339
To fix this one #46132 need to a little bit tweak the algorithm for picking up the best constructor. In the last commits, I tried to do it. Please review. I don't know how the idea of fallback constructors will affect performance.

[eerhardt]

Thanks for getting this fix up @mapogolions. It looks like a great start.

FYI - @davidfowl@halter73@Tratcher - in case you want to take a look and have any feedback.

[eerhardt]

Thanks for adding this test. Can you also add one that ensures the default constructor is picked in this scenario?

dotnet/maui#4318 (comment)

Basically:

[Theory][InlineData(typeof(DefaultConstructorFirst)][InlineData(typeof(DefaultConstructorLast)]
public voidChoosesDefaultConstructorNoMatterOrder(TypeinstanceType){var services =newServiceCollection();usingvarprovider= services.BuildServiceProvider();var instance =ActivatorUtilities.CreateInstance(provider,instanceType);Assert.NotNull(instance);}public class DefaultConstructorFirst
{publicA A {get;}
public B B {get;}
public DefaultConstructorFirst(){}
public DefaultConstructorFirst(ClassAa){A=a;}
public DefaultConstructorFirst(ClassAa,ClassBb){A=a;B=b;}}
public classDefaultConstructorLast{
public A A {get;}
public B B {get;}
public DefaultConstructorLast(ClassAa,ClassBb){A=a;B=b;}
public DefaultConstructorLast(ClassAa){A=a;}
public DefaultConstructorLast(){}}

[eerhardt]

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintApplyExactLength{get;privateset;}=-1;

[eerhardt]

Maybe picking a better name here would help. How about

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintMatchedLength{get;privateset;}=-1;

[eerhardt]

The existing code passes false in for inherit. The new code uses a different overload that passes true for inherit. It's possible that this doesn't really matter for constructors, but I'd prefer to limit the changes to only what is necessary to fix the issue.

Suggested change

	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute)))
	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute),false))

[eerhardt]

I'm thinking about 2 optimizations here:

1. When there is only a single constructor, just use it.
2. When there are more than one, is there a way to not allocate an array here? Possibly we could stackalloc up to a reasonable count? Maybe 5 or 10? If the Type has more than that, then allocating an array seems OK since it won't be that common.

Maybe if we do (2), then special-casing (1) becomes unnecessary.

[eerhardt]

Might as well make the Match method return void since no one is consuming the return value anymore.

[Tratcher]

Prior related discussion: dotnet/aspnetcore#2871

[mapogolions]

@eerhardt
Thanks for feedback. Could you please review changes. As I understand from the comment above the ActivatorUtilities class should use the longest available constructor now. I've tried to address it. The new requirement breaks the following test case so I fixed it.

[eerhardt]

Why should B be null here? There is a scoped service for B, so shouldn't the ctor that takes a B be picked?

[mapogolions]

As I understand from dotnet/aspnetcore#2915, the longest available constructor should only be used if competing constructors
have the same priority/score (the value of the MatchedLength property reflects it)

Creatable class has two constructors

• Ctor(A a, B b, C c, S s)
• Ctor(A a, C c, S s) : this(a, null, c, s)

Let's look at the following 3 examples

1. ActivatorUtilities.CreateInstace(provider, new A(), new C());

According to the algorithm that was invented and used now and which I took as a basis, the first ctor is given score 1, the second one is given score 2 (2 given arguments match sequentially). As result the second constructor will be picked up (b is null)

2. ActivatorUtilities.CreateInstance(provider, new A())

The first ctor is given score 1, the second ctor is given score 1. We fall into a situation where we have competing constructors. In this case, the rule about the longest available constructor comes into play.

3. ActivatorUtilities.CreateInstance(provider, new C(), new A()) or ActivatorUtilities.CreateInstance(provider)
   Same as above, except for the fact that competing constructors are given score 0.

[eerhardt]

In the discussion in #46132, it is asking for an ambiguous exception to be thrown to be thrown in this case. Which seems like the right thing IMO. If there are multiple ctors that we can't really pick between, it is better to throw and say "use the ActivatorUtilitiesConstructorAttribute to disambiguate". It is really hard to define perfect behavior here when the "given arguments" and the "services available" can intermix.

See also all the discussion on #46132 for all the scenarios, and the intended behaviors.

[eerhardt]

@mapogolions - any thoughts on this?

[mapogolions]

@eerhardt I don't see a way to satisfy all the mentioned requirements (especially ambiguity detection). Feel free to close this as a dead end.

[eerhardt]

What about using the new (in 6.0) IServiceProviderIsService interface to test if a Type is available as a service in the IServiceProvider?

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

Lines 8 to 19 in b098b6f

	/// <summary>
	/// Optional service used to determine if the specified type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	publicinterfaceIServiceProviderIsService
	{
	/// <summary>
	/// Determines if the specified service type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	/// <param name="serviceType">An object that specifies the type of service object to test.</param>
	/// <returns>true if the specified service is a available, false if it is not.</returns>
	boolIsService(TypeserviceType);
	}

If the IServiceProvider doesn't support this new interface, then using the algorithm proposed here?

[eerhardt]

Closing as per #67493 (comment). Will either re-open or open a new PR to fix this issue.

[mapogolions]

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

[ghost]

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

Issue Details

---

If we have a type with some number of constructors, then the activator always finds the best constructor to activate the instance. This is independent of the order in which these constructors were defined.
Let's look at the following class

classValidationResult{publicValidationResult(ValidationStatusstatus,stringdescription,IReadOnlyDictionary<string,object>data){Status=status;Description=description;Data=data;}publicValidationResult(stringdescription,IReadOnlyDictionary<string,object>data):this(ValidationStatus.Valid,description,data){}publicValidationStatusStatus{get;}publicstringDescription{get;}publicIReadOnlyDictionary<string,object>Data{get;}}

varinstance=ActivatorUtilities.CreateInstance<ValidationResult>(serviceProvider,"description",data);

The activator will select the second constructor. (i.g. the statement instance.Status is ValidationStatus.Valid will be true)

But if we start using the ActivatorUtilitiesConstructor attribute, then the order in which constructors are defined starts to affect the final result.
Please see unit tests for more details

Author:	mapogolions
Assignees:	-
Labels:	area-Extensions-DependencyInjection
Milestone:	-

[am11]

It is wasteful to construct an array, then only use its first element and throw away the rest. This block can be structured like this:

ConstructorInfo?constructorInfo=null;foreach(ConstructorInfo?ctorinctors){if(ctor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute))){if(constructorInfois not null){ThrowMultipleCtorsMarkedWithAttributeException();}constructorInfo=ctor;}}if(constructorInfois not null){ConstructorMatcherbestMatcher=new(constructorInfo);bestLength=bestMatcher.Match(parameters);if(bestLength==-1){ThrowMarkedCtorDoesNotTakeAllProvidedArguments();}}

This will also make using System.Linq; unnecessary.

[mapogolions]

@am11 Thanks for review. Good point

[am11]

Suggested change

	varmatcher=newConstructorMatcher(constructor);
	if(constructorisnull)
	{
	continue;
	}
	varmatcher=newConstructorMatcher(constructor);

[mapogolions]

@am11 What do you think if we just replace ConstructorInfo? with the ConstructorInfo in the foreach-loop foreach (ConstructorInfo?ConstructorInfo constructor in constructors)? According to documentation the GetConstructors() call should not return collection with nullable elements. https://docs.microsoft.com/en-us/dotnet/api/system.type.getconstructors?view=net-6.0#system-type-getconstructors

[am11]

Yes, makes sense. Based on the usage elsewhere in the repo, null is not checked. GetConstructor (singular), however, returns nullable object,

[eerhardt]

Thanks @mapogolions. Can you also ensure the scenarios listed in #46132 are addressed here as well?

Likewise, while we are fixing this bug, we should ensure the .NET Maui scenario is fixed as well, where the order of constructors looks like this:

publicLoginView(RandomItem item){//this is constructor is invoked by code and RandomItem is not registered in DI//therefore it should be skipped by ActivatorUtilities.CreateInstanceInitializeComponent();}// since there are no other valid constructors, ActivatorUtilities.CreateInstance should pick the default ctorpublicLoginView(){InitializeComponent();}

[mapogolions]

@eerhardt
Initially this PIR fixed this problem #42339
To fix this one #46132 need to a little bit tweak the algorithm for picking up the best constructor. In the last commits, I tried to do it. Please review. I don't know how the idea of fallback constructors will affect performance.

[eerhardt]

Thanks for getting this fix up @mapogolions. It looks like a great start.

FYI - @davidfowl@halter73@Tratcher - in case you want to take a look and have any feedback.

[eerhardt]

Thanks for adding this test. Can you also add one that ensures the default constructor is picked in this scenario?

dotnet/maui#4318 (comment)

Basically:

[Theory][InlineData(typeof(DefaultConstructorFirst)][InlineData(typeof(DefaultConstructorLast)]
public voidChoosesDefaultConstructorNoMatterOrder(TypeinstanceType){var services =newServiceCollection();usingvarprovider= services.BuildServiceProvider();var instance =ActivatorUtilities.CreateInstance(provider,instanceType);Assert.NotNull(instance);}public class DefaultConstructorFirst
{publicA A {get;}
public B B {get;}
public DefaultConstructorFirst(){}
public DefaultConstructorFirst(ClassAa){A=a;}
public DefaultConstructorFirst(ClassAa,ClassBb){A=a;B=b;}}
public classDefaultConstructorLast{
public A A {get;}
public B B {get;}
public DefaultConstructorLast(ClassAa,ClassBb){A=a;B=b;}
public DefaultConstructorLast(ClassAa){A=a;}
public DefaultConstructorLast(){}}

[eerhardt]

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintApplyExactLength{get;privateset;}=-1;

[eerhardt]

Maybe picking a better name here would help. How about

Suggested change

	publicintApplyExectLength{get;privateset;}=-1;
	publicintMatchedLength{get;privateset;}=-1;

[eerhardt]

The existing code passes false in for inherit. The new code uses a different overload that passes true for inherit. It's possible that this doesn't really matter for constructors, but I'd prefer to limit the changes to only what is necessary to fix the issue.

Suggested change

	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute)))
	if(constructor.IsDefined(typeof(ActivatorUtilitiesConstructorAttribute),false))

[eerhardt]

I'm thinking about 2 optimizations here:

1. When there is only a single constructor, just use it.
2. When there are more than one, is there a way to not allocate an array here? Possibly we could stackalloc up to a reasonable count? Maybe 5 or 10? If the Type has more than that, then allocating an array seems OK since it won't be that common.

Maybe if we do (2), then special-casing (1) becomes unnecessary.

[eerhardt]

Might as well make the Match method return void since no one is consuming the return value anymore.

[Tratcher]

Prior related discussion: dotnet/aspnetcore#2871

[mapogolions]

@eerhardt
Thanks for feedback. Could you please review changes. As I understand from the comment above the ActivatorUtilities class should use the longest available constructor now. I've tried to address it. The new requirement breaks the following test case so I fixed it.

[eerhardt]

Why should B be null here? There is a scoped service for B, so shouldn't the ctor that takes a B be picked?

[mapogolions]

As I understand from dotnet/aspnetcore#2915, the longest available constructor should only be used if competing constructors
have the same priority/score (the value of the MatchedLength property reflects it)

Creatable class has two constructors

• Ctor(A a, B b, C c, S s)
• Ctor(A a, C c, S s) : this(a, null, c, s)

Let's look at the following 3 examples

1. ActivatorUtilities.CreateInstace(provider, new A(), new C());

According to the algorithm that was invented and used now and which I took as a basis, the first ctor is given score 1, the second one is given score 2 (2 given arguments match sequentially). As result the second constructor will be picked up (b is null)

2. ActivatorUtilities.CreateInstance(provider, new A())

The first ctor is given score 1, the second ctor is given score 1. We fall into a situation where we have competing constructors. In this case, the rule about the longest available constructor comes into play.

3. ActivatorUtilities.CreateInstance(provider, new C(), new A()) or ActivatorUtilities.CreateInstance(provider)
   Same as above, except for the fact that competing constructors are given score 0.

[eerhardt]

In the discussion in #46132, it is asking for an ambiguous exception to be thrown to be thrown in this case. Which seems like the right thing IMO. If there are multiple ctors that we can't really pick between, it is better to throw and say "use the ActivatorUtilitiesConstructorAttribute to disambiguate". It is really hard to define perfect behavior here when the "given arguments" and the "services available" can intermix.

See also all the discussion on #46132 for all the scenarios, and the intended behaviors.

[eerhardt]

@mapogolions - any thoughts on this?

[mapogolions]

@eerhardt I don't see a way to satisfy all the mentioned requirements (especially ambiguity detection). Feel free to close this as a dead end.

[eerhardt]

What about using the new (in 6.0) IServiceProviderIsService interface to test if a Type is available as a service in the IServiceProvider?

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

Lines 8 to 19 in b098b6f

	/// <summary>
	/// Optional service used to determine if the specified type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	publicinterfaceIServiceProviderIsService
	{
	/// <summary>
	/// Determines if the specified service type is available from the <see cref="IServiceProvider"/>.
	/// </summary>
	/// <param name="serviceType">An object that specifies the type of service object to test.</param>
	/// <returns>true if the specified service is a available, false if it is not.</returns>
	boolIsService(TypeserviceType);
	}

If the IServiceProvider doesn't support this new interface, then using the algorithm proposed here?

[eerhardt]

Closing as per #67493 (comment). Will either re-open or open a new PR to fix this issue.