[Request] Consider orchestrating ConfigurationProviders as a pipeline instead of centrally

[penenkel]

Is there a specific reason that value resolution is controlled centrally from within the ConfigurationRoot?
By that I mean that Configuration[key] currently calls TryGet(key) on each provider in order until it gets a value. This also means that providers know nothing of one and other and cannot react in any way to the values provided by the others.

Disadvantage of current design

As it stands any customization which departs from the current each provider layer independently adds keys behavior requires changing ConfigurationRoot. Unfortunately, as ConfigurationRoot is hardwired into the ConfigurationBuilder, one cannot easily switch out the default implementation with a custom one.

My vision

I envision a pipeline like architecture (comparable to the middleware pipeline) where each provider is responsible for calling the next one in line. When a value is requested for a key, each provider (starting from the first/top one) gets to decide if it can (or wants to) provide a value and can otherwise delegate the request to the next provider in line. This would still allow replicating the current behavior but it would also support "interceptor-like" providers which can modify (or hide) values from the underlining provider layers.

Effect

This would allow implementing things like resolving references or value interpolation (or any other kind of intercepting value modification) fairly easily as additional "provider" layers, with the additional advantage that those would be optional and customizable at the (framework-)users discretion.

[analogrelay]

Having each provider be able to have full control to rewrite the entire config system seems like it would cause a lot of user confusion. The current system is designed to be fairly simple: Each provider produces a flat list of key-value pairs (as represented by calls to TryGet) and they are merged. It's a fairly straightforward system to explain.

In addition, a dramatic change to the config model like this would be a major breaking change in a core component with a lot of users. I don't think I see the benefit outweighing the very high cost.

[penenkel]

The point about breaking changes is certainly a concern. I would suggest mitigating this by replicating the current behavior by default (as mentioned in the initial post). This would hopefully reduce the breaking changes to only affect existing custom provider implementations.

The argument about additional complexity and potential user confusion doesn't really convince me. The proposed config system would still be far less complex than the Option system and would also have conceptually close analogue in the middleware-pipeline.

As for the benefits: I see the primary benefit in opening the way for straight forward solutions of several other feature requests, which then could be easily provided by community driven projects.
Override/clear arrays: dotnet/extensions#2967, dotnet/extensions#607
Resolve references: dotnet/extensions#2804, dotnet/extensions#1787, dotnet/extensions#1721, dotnet/extensions#778

[ghost]

As part of the migration of components from dotnet/extensions to dotnet/runtime (aspnet/Announcements#411) we will be bulk closing some of the older issues. If you are still interested in having this issue addressed, just comment and the issue will be automatically reactivated (even if you aren't the author). When you do that, I'll page the team to come take a look. If you've moved on or workaround the issue and no longer need this change, just ignore this and the issue will be closed in 7 days.

If you know that the issue affects a package that has moved to a different repo, please consider re-opening the issue in that repo. If you're unsure, that's OK, someone from the team can help!

[penenkel]

Hi, I still think this feature would be worthwhile. I can understand that it is probably low priority.

I would consider it a satisfactory compromise if the ConfigurationRoot class would be made replaceable, so that I can roll my own configuration mechanism.

[ghost]

Paging @dotnet/extensions-migration ! This issue has been revived from staleness. Please take a look and route to the appropriate repository.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.