Closed ryangribble closed 4 years ago
NOTE: It does appear the EnvionmentVariables providers have different prefixes "ASPNETCORE_"
"DOTNET_"
and ""
so I guess that does start to make things clearly if they come from different areas/layers of the eco system...
@ryangribble thanks for contacting us.
As you mention, this is this way because the information comes from multiple sources at different levels, for example hosting has a provider that handles ASPNETCORE_...
environment variables that are used to set up things like listening urls etc.
See https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-3.0#default-configuration for more details
/cc:@tratcher in case he wants to add anything else.
Hope that helps
Describe the bug
The "default"
IConfiguration
provided toStartup
seems overly complex, containing multiple nested providers with duplicates/triplicates in places. This causes difficulty in reasoning about how the default configuration setup should work!I'm mostly interested in whether this is intentional (and if so what the reasoning is) or whether it is inadvertent (passing around builders through various parts of the framework, with multiple places adding providers onto an already complicated provider list?)
To Reproduce
dotnet new webapi
Set a breakpoint in
Startup.cs
Configure()
method and inspect theConfiguration.Providers
property at run time.It contains 5 top level providers and a total of 3 nested levels, with EnvironmentVariables in the list 3 times and CommandLine being in the list 2 times.
The heirarchy is as follows (indentation showing the child items of the
ChainedConfigurationProvider
s):This seems overly complicated and in my case has led to unexpected behaviour trying to reason about how configuration values are ultimately being surfaced!
Further technical details
dotnet --info