Considering Microsoft’s chained configuration approach and the number of configuration providers supported these days, it can be difficult investigating issues.
Here are a few that you as an engineer may be asking.
When using DefaultHostBuilder, Azure will override launch settings, app settings, environment variables, and passed-in arguments — just about everything. There are ways around this, like reordering the chained configuration providers, or not using DefaultHostBuilder and add in to the code the configuration manually that is wanted.
A hierarchy exists when it comes to chained configuration providers:
This is the order in which each chained configuration provider is applied. Last one wins.
1. Environment variable
2. AppSettings.json
3. AppSettings.{{DOTNET_ENVIRONMENT}}.json
4. Command-line argument
5. LaunchSettings.json (if DOTNET_ENVIRONMENT is “Development” and running from Visual Studio)
6. Azure App Configuration
If you want to understand more about what overrides what when it comes to environment variables, command-line arguments, appsettings, launch settings, and Azure, check out this demo project on Github.
Common reasons include
1) DOTNET_ENVIRONMENT is not set to “Development” — ASPNETCORE_ENVIRONMENT will not work here
2) An Azure property is overriding the property in the appsettings.Development.json
3) Incorrect format in the appsettings.Development.json
4) Does the code use DefaultHostBuilder? Otherwise, the app will need to add the appsettings* files in its configuration.
In the Program.cs app configuration, add a .ConfigureServices if not already present to gain access to the hostContext. Set a breakpoint and run in debug to the breakpoint. Then, examine hostContext.Configuration to see the providers and what each contains.
In the Program.cs app configuration, add a .ConfigureServices if not already present to gain access to the hostContext. Here, or in a extension method, you can convert hostContext.Configuration to an enumerable, and enumerate through the keys and values, logging each one — or logging what matches to a pre-defined set of keywords.
Security Warning: you may not want to dump everything out blindly, especially in production logs, as there may be secrets, keys, connections, or passwords in the configuration.
