ASP.NET Core configuration precedence with launchSettings, user secrets and appsettings.* across environments

ASP.NET Core configuration is layered across launchSettings.json, user secrets, appsettings.json and environment-specific files such as appsettings.Development.json. Visual Studio debug profiles commonly set ASPNETCORE_ENVIRONMENT and rely on development-only sources, while production relies on published files and host environment variables.

The precise goal is to define a consistent source of truth for each setting class and to document the intended winner when the same key exists in multiple providers. launchSettings.json and user secrets are development conveniences and are not deployed. appsettings.json is normally published, while environment-specific JSON files are loaded only when the environment name matches.

Provider ordering can vary by ASP.NET Core generation and hosting model, creating uncertainty about precedence when a key is present in both an environment variable and an environment-specific JSON file. Teams need a clear decision on ownership rather than relying on implicit override behavior.

Which provider order should be adopted for production to ensure environment variables override appsettings.Production.json? Should appsettings.Development.json ever be published, or should all non-default values be moved to environment configuration? How to document the intended source of truth for each setting class without relying on local debug behavior?