Where are appsettings after compiled in a dotnet core 2.1

0
votes

I am trying to understand how the appsettings.json and appsettings.{Environment}.json and the environment variables play along in a dotnet core 2.1 application but I don't know how at runtime the appsettings (whatever the final transformation is) are accessed by the application.

I would expect to have the appsettings among the compiled dll (e.g: MyWebApiApp\bin\Debug\netcoreapp2.1), but I don't see it there.

Understanding this would help me find out the best approach for OpenShift configmaps vs appsettings, because I need to know whether I should rely on appsettings at runtime or whether appsettings is something useful for development but on production I should rely on environment variables rather.

Thanks!

1
.net-coreappsettings

1 Answers

1
votes

Are you running the code from within Visual Studio? The default CreateDefaultBuilder uses the Directory.GetCurrentDirectory() to determine which folder to load the settings files from. When you are running from within Visual Studio the current directory is your project directory - so when you run/debug the program it finds the correct settings file.

One way to test this is to change to a command line and run your applications using dotnet myapp.dll. If you are loading settings from an appsettings file it will not find the file and the settings will be null.

If you change the properties on your appsettings file to copy if newer and rebuild your app, when you run it from the command line it will correctly find the settings file.

You can take a look at the how the webhost determines which settings to use by looking at the implementation file. But, in short, dotnetcore will use settings in the following order:

  • appsettings.json
  • environment variables
  • command line

The documentation for this is here

So, if there are settings that could change once the app is deployed then you can overwrite them via environment variables. You could redeploy the appsettings files if you want to configure that way but, from my experience, it is much easier to handle production settings via environment variables, possibly using a third party tool e.g. puppet.

Hope that helps.