[release/6.0] Undo breaking change in 6.0 in environment variable configuration prefix support #62916
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #62819 to release/6.0
/cc @maryamariyan
Customer Impact
Customer reported break from .NET 5.0 behavior.
Using the default configuration, the
EnvironmentVariablesConfigurationProvider
loads configuration from environment variable key-value pairs. For environment variables containing double underscores in the key name (e.g.A__B
), the double underscores__
gets replaced by:
(becomingA:B
) by the environment variable configuration provider as the configuration key value.Now, if we end up using
AddEnvironmentVariables
API with prefix value ofMY:PREFIX:
then we expect that a configuration key namedMY_CONFIG
to get properly populated with the value set by an environment variable set asMY__PREFIX__MY_CONFIG
. This is a scenario that got regressed in .NET 6 by bugfix PR #42932.We submitted a regression fix such that when using environment variable configuration, it brings back the support for prefix being normalized like it was in .NET 5.0.
The regression fix reverts changes made in https://github.com/dotnet/runtime/pull/42932/files while updating tests to reduce ambiguity of what the expected behavior should be.
Link to original pr fix: #42932
Link to new pr fix: #62819
Testing
Available in pr #62819
To mitigate and reduce ambiguity we updated tests and we also look to add more documentation as well.
Risk
Low risk, because it would revert changes back to match logic in 5.0 and before.
What is the risk from 6.0 to 6.0.2 with this change?
Low, because we did not fully advertise the 6.0 change already in any breaking change doc so the chances of someone relying on the 6.0 behavior is low.