Configurations in .NET Core

Realizing this, Microsoft made configuration a first-order concept in .NET Core and did so in quite a flexible, extensible way. It all starts with a builder instance; we add providers to it, and when we've finished, we just ask it to build a configuration object that will hold all the values loaded from each provider in memory.

This configuration object will be capable of returning configuration settings from any of the added providers transparently, which means that regardless of the source, we use the same syntax for querying configuration options. It will hold an in-memory representation of all the values loaded from all registered providers, and will allow you to change them, or add new entries.

The base class model for the configuration application programming interface (API) in .NET Core looks like this:

So, the provider mechanism is split into two base interfaces and their implementations, as follows:

• IConfigurationSource is responsible for creating a concrete instance of an IConfigurationProvider; each of the available providers (coming next) implements this interface.
• IConfigurationProvider specifies the contract for actually retrieving values, reloading, and more; the root class that implements this is ConfigurationProvider, and there's also a particular implementation that serves as the root for all file-based providers, FileConfigurationProvider.

ConfigurationBuilder itself is just a specific implementation of the IConfigurationBuilder interface, and there are no other implementations. Its contract specifies how we can add providers and build the configuration from them, as illustrated in the following code block:

var builder = new ConfigurationBuilder()     .Add(source1)
    .Add(source2);

var cfg = builder.Build();

As for the configuration itself, there are three base interfaces, as follows:

• IConfiguration: This specifies the methods for retrieving and setting configuration sections and values, monitoring changes, and more.
• IConfigurationRoot: This adds a method for reloading the configuration to IConfiguration and the list of providers used to build the configuration.
• IConfigurationSection: This is a configuration section, meaning that it can be located somewhere beneath the configuration root in a location identified by a path (the keys of all of the parent sections, up to and including its own key) and a key that uniquely identifies that section in its parent.

We will shortly see the ways by which we can use the configuration values, but for now, it is worth mentioning that we can retrieve and set individual settings through the overloaded [] operator in IConfiguration, like this:

cfg["key"] = "value";
string value = cfg["key"];

This takes a string as key and returns a string as the value, and in the next sections, we will see how we can circumvent this limitation. If no entry for the given key exists, it returns null.

The .NET Core configuration has the concept of sections. We can get hold of a particular section, or even check whether it exists altogether, by running the following code:

var section = cfg.GetSection("ConnectionStrings");
var exists = section.Exists();

By convention, sections are separated by :. Getting a value from a section with a section-specific key is the same as retrieving it from the configuration root with a fully qualified key. For example, if you have a key of A:B:C, this is the same as having a key of C inside section B of section A, as illustrated in the following screenshot:

var valueFromRoot = cfg["A:B:C"];
var aSection = cfg.GetSection("A");
var bSection = aSection.GetSection("B");
var valueFromSection = bSection["C"];

For the record, the core configuration API is implemented in the Microsoft.Extensions.Configuration and Microsoft.Extensions.Configuration.Binder NuGet packages, which are automatically included by other packages, such as those of the specific providers. Let's now have a look at the available providers.