Add ServiceProvider-aware extension methods to ServiceCollectionExtensions

[thomhurst]

This should allow for much more flexibility.

Consumers can use their built services or options, or can utilise things like .PostConfigure<TOptions> and retrieve the IOptions<TOptions> from inside the lambda via the ServiceProvider.

The latter is actually what I'm wanting to do because I have a TestServer where I override some configuration dynamically, but without access to the service provider this is proving difficult.

[CLAassistant]

All committers have signed the CLA.

[iancooper]

Hi @thomhurst.

First, thanks for the contribution. Always appreciated. I have a few questions.

Can you explain the design here? An issue or ADR always helps. Is your goal here to add support for IConfigure?

• It is worth noting that our use of BrighterOptions predates the adoption of IOptions<TOptions> by .NET
• Also worth noting is our use of a DI-Friendly Framework approach, which means that Brighter itself does not depend on a DI framework but on factories. We provide implementations of those factories for ServiceCollection as a convenience
• I note that you added a set of UseXXX methods. We moved away from these in favor of asking folks to set their values via BrighterOptions, to simplify our API. Before we add these back in, what do you want to achieve by adding them?

I am sure it will help, but want to help an old man understand what you are trying to achieve?

[thomhurst]

Hi @thomhurst.

First, thanks for the contribution. Always appreciated. I have a few questions.

Can you explain the design here? An issue or ADR always helps. Is your goal here to add support for IConfigure?

• It is worth noting that our use of BrighterOptions predates the adoption of IOptions<TOptions> by .NET
• Also worth noting is our use of a DI-Friendly Framework approach, which means that Brighter itself does not depend on a DI framework but on factories. We provide implementations of those factories for ServiceCollection as a convenience
• I note that you added a set of UseXXX methods. We moved away from these in favor of asking folks to set their values via BrighterOptions, to simplify our API. Before we add these back in, what do you want to achieve by adding them?

I am sure it will help, but want to help an old man understand what you are trying to achieve?

Chucked you a message on slack 😄

[thomhurst]

Had to split some stuff out because quality gates were failing as too complex. Let me know any more changes you'd like to see