Dependencyinjection: ActivatorUtilities prefers default ctor over parameterful ctor

[GrabYourPitchforks]

Define a class with two constructor overloads:

.ctor()
.ctor(IServiceProvider services)

ActivatorUtilities.CreateInstance will call the parameterless ctor even though the parameterful ctor is a better match.

[Antaris]

You say _better_ match but that is your assumption because you understand the intent of your code, the ActivatorUtilities type doesn't.

I think a better solution would be to review your code to understand why you have each constructor and if using ActivatorUtilities is the right way to go.

Should you be resolving through the DI container instead using a component registration which says which constructor to use?

[khellang]

According to @pakrym in https://github.com/aspnet/HttpAbstractions/pull/475, this shouldn't be an issue anymore?

[davidfowl]

ctor injecton is fine, ActivatorUtilities is not.

/cc @pranavkm

[pranavkm]

Yeah - the issue is that we cannot introspect what services are registered in a container without realizing it in ActivatorUtilities. That's too expensive to determine the best match.

[Eilon]

Moving this to Backlog as we are not planning to make any changes for this at this time.

[divega]

@Eilon @pranavkm can we consider assigning this to the 1.2 release? We have hit it multiple times and it seems to make sense to make the behavior more consistent.

cc @anpete @bricelam @AndriySvyryd

[Eilon]

@divega we can certainly consider it, but isn't it a breaking change?

Plus we'll need to look at the perf concern.

[divega]

@Eilon I would suggest you let the user choose. What we do currently maybe the fastest option but I believe it is less likely to satisfy the user's requirements and expectations.

[Eilon]

So the suggestion is to add a flag to get the new behavior? That's certainly reasonable...

[divega]

Yes, a flag on the methods that take a service provider is what I had in mind, although there might be bit of an explosion of methods with it.

[Antaris]

@divega How would such a flag work, something like [Preferred] which the ActivatorUtilities type would look for?

[divega]

@Antaris I will totally leave that to the DI folks.

That said, what I had in mind was new methods or new overloads of the existing methods which take a bool or an enum (making sure the new parameter is not ambiguous with the params arguments) to control the behavior.

What you say could be nice, but I would expect such attribute to play a role in selecting the constructor when instantiating a service (as opposed to only affecting ActivatorUtilities) and that is something I am not sure we would do if it only worked with our DI container.

[Eilon]

See also: https://github.com/aspnet/DependencyInjection/issues/464

[Eilon]

No plans to do this.