Infrastructure: Add parameter objects and service rewriting code to avoid breaking base class D.I. constructors in patch/point releases

[ajcvickers]

When a service is overridden by a provider, the provider must call the base service constructor. This means it becomes a breaking change when base service gets new dependencies such that its constructor needs to change.

We previously implemented a mechanism whereby additional services could be injected as part of the provider service resolution mechanism. This worked because provider services were always registered through a delegate, and so we could add code to that delegate as needed to inject services. Following #7457 services are registered by the provider explicitly in the container, which is much preferable for perf, but means that there is no hook to inject services.

[jnm2]

I'm super curious what you come up with. I've hit this in my own unrelated architectures.
I've been thinking about the fact that the BCL best practice for adding parameters to event handlers in a back-compatible way is to define an EventArgs from the start.
Compared to straight up constructor injection it feels like quite some overhead to write a DependencyArgs for each class, yet we've done it for every event for years so maybe it's not as bad is it first seems.

The DependencyArgs subclass could itself be recognized and constructor injected by the IoC container and the subclass could provide getter-only autoproperties which could be added to at any time. The understanding would be that this class is only to be instantiated by the IoC container, so perhaps making the constructor internal or private or obsolete would help prevent library consumers' code from misunderstanding and calling the constructor.

If you don't see any value to inheritance, or even want to make it impossible, DependencyArgs could be an immutable struct and be recognized by the IoC container by name convention or by attribute or by the parameter name used to inject it. For example, it could always be a nested struct within the service named DependencyArgs. It should probably be nested in any case.

Just thinking out loud.

[popcatalin81]

How about just passing a single IServiceProvider parameter to all base services, and to allow customization of per provider create a wrapper IServiceProvider for each provider.

Edit: I've meant IServiceProvider not IServiceCollection

[ajcvickers]

@jnm2 @popcatalin81 Passing an IServiceProvider is probably what we will end up doing, but also what we hope to avoid doing because it results in use of the service locator pattern, which then obscures dependencies. I suspect we will use this pattern along with adding [Obsolete] to the existing constructor while at the same time introducing a new constructor with the new dependency added explicitly. Then at next major version rev we will remove the obsolete constructor.

[ajcvickers]

Discussed in design meeting and decided to try the parameter object approach for services, using sealed classes. Considered composition, but this would be a big change to the architecture and design of certain services.