Introduction

Previously we had the Web.Config and App.Config files in our .Net Framework applications, which were actually XML files, where we could put the settings of our applications, and together with them, we used the ConfigurationManager class to access them.

Often these files became real monsters and their maintenance traumatizing to many developers.

With the launch of .Net Core and ASP.Net Core a few years ago, we gained a new, more powerful, flexible, and simple configuration engine.

Multiple data sources

In addition to JSON files like the famous appsettings.json, the new .Net Core configuration API allows us to have more flexibility when choosing the source of our settings. We can have several such as:

• JSON files;
• XML files;
• INI files;
• Environment variables;
• Collections in memory;
• Command line arguments;
• External sources such as database.

In addition to the sources mentioned above, you can create your own configuration provider to read other data sources using the IConfigurationSource and IConfigurationProvider interfaces.

Multiple configuration files

As in the old Web / App.Config, our list of configurations consists of a key/value set, and can be distributed in hierarchically organized, environment-separated files.

For example, we can have one file for each specific environment in our development flow.

What defines which environment to run is the ASPNETCORE_ENVIRONMENT (environment variable). The value of this variable is what defines which environment we are running.

In the development environment, on the developer machine, it can be found in the launchSettings.json file, or in the properties of your project. On a system running in the production environment, this environment variable must be registered in the operating system.

Overriding values

Typically, values that do not change can be stored in the appsettings.json file, and in the other files you can only put the values that change according to the environment in which they are running because they are overwritten in memory during the execution of your application.

Initialization of the configuration engine

It is in the ConfigurationBuilder class where it begins to happen. It is available in the Microsoft.Extensions.Configuration Nuget package.

First of all, we must create a new instance of ConfigurationBuilder, informing which providers we want to use as configuration source.

Many developers are unable to access the appsettings.json configuration file in a console-like application in .Net Core; this is due to the fact that the code snippet above is not done automatically in this type of application – you must enter it manually.

In ASP.Net Core 2.x applications there is no need to insert this code snippet as this is already done automatically by calling the WebHost.CreateDefaultBuilder method, which you can see in the Program class of your application, and then an instance of IConfiguration is passed in the Startup class constructor.

In previous versions of ASP.Net Core, this configuration was done directly in the constructor of the Startup class.

Reading configuration values

As you might imagine, we should use the keys described in our configuration files to read their values. For this, we can use the IConfiguration interface mentioned earlier, which is available in the Nuget package Microsoft.Extensions.Configuration.Abstractions.

It can be injected into your class through the constructor, and with that we can read the values through its GetValue <T> methods, by entering the key from which we want to get the value.

Values are always stored as a string by default, however, please note that I enter the appropriate data type to return the value so that the appropriate conversion is done. In this case, if you are reading numeric values, you can make the call as configuration.GetValue (“key”), for example.

In addition to the configuration values stored in files, you can read the environment variables of your operating system.