Override appSettings during development – .NET Core

Posted by

Sometime back, I had written about how to override appSettings during development in traditional ASP.NET application.

Recently, we started development of a ASP.NET Core application and had a similar challenge. Our developers work on different operating systems (Windows and Mac). They have different local connection strings and application settings. We had a same problem as earlier: How do we ensure that we do not store developer specific app settings/ connection string in source control.

Configuration in ASP.NET Core is quite advance and extensible as compared to traditional ASP.NET Framework. We have multiple ways to solve this problem. From the documentation:

App configuration in ASP.NET Core is based on key-value pairs established by configuration providers. Configuration providers read configuration data into key-value pairs from a variety of configuration sources:

  • Azure Key Vault
  • Command-line arguments
  • Custom providers (installed or created)
  • Directory files
  • Environment variables
  • In-memory .NET objects
  • Settings files

Also, ASP.NET Core offers following two recommended ways to store app secrets during development:

  • Environment variables
  • Secret Manager

One of the issue, with the above two approaches is that the settings are stored outside the IDE. Also, since these settings override the appSettings.json file it can cause confusion while debugging as the developer may not realize that settings are being overridden.

Our Approach

For our project we were looking for the simplest possible solution without any additional overhead. The easiest possible solution us for was to use appSettings.Developement.json file to store local settings and exclude it from source control by adding to .gitignore (we use Git).

However, we already have a separate “Dev” environment where we first deploy our application before pushing to Test and Live environments. Using the default Developement environment for the purpose of storing the local settings could have confused the developers.

As a result, we ended up adding a new appSettings.Local.json file to the project. This setting file was then added to .gitignore to exclude this file from source control.

Here is a sample appSettings.Local.json

We then, changed our launchsettings.json and updated ASPNETCORE_ENVIRONMENT to point to Local instead of Development

Last but not the least, we updated Startup.json to use developer exception page while doing development.

That’s it! This approach helped us to keep all our settings in one place (within our IDE) and it turned out to be a pretty neat solution to our problem.

Hope you find this tip useful. Please share your thoughts in comments section below.


Advertisements