title: .Net Core appsettings.json best practices - override dev settings (or vice versa)?
body: <p>Looking for a sensible approach in regards to structuring appsettings.json files in .Net Core.</p>
  
  <p>Should the base 'appsettings.json' file be configured for running in a dev environment, and then environment based overrides such as appsettings.production.json overwrite specific keys for production?</p>
  
  <p>Or should appsettings.json only contain config that is shared across ALL environments, and then a specific appsettings.development/staging.json file used to explicitly set keys for those environments?</p>
  
  <p>My concern is - say an app is deployed to a live server, but a key stored in an environment variable (e.g. to override connection string) is missing or spelt wrong etc. In this case the app would fall back to the base appsettings.json connection string which would be the incorrect DB for the live environment. A scenario like this sounds pretty disasterous, particularly as this could easily go unnoticed?</p>
  
  <p>So really the question boils down to - should the contents of the base appsettings.json file be 'dev' values as default (e.g. dev DBs, sandbox APIs) that are overridden with production data, or vice versa?</p>