How .NET Load Environment Specific Configuration

Summary

The .NET configuration builder simplifies the process of loading environment-specific configurations, allowing developers to easily manage different settings for various environments such as schema, staging, and production.

Abstract

The .NET framework provides a robust configuration builder tool that enables developers to manage environment-specific configurations efficiently. This is particularly useful when working across different environments like schema, staging, release, QA, and production, where specific settings such as database connection strings or signal configurations need to be adjusted. By creating environment-specific JSON configuration files, such as schema.json and staging.json, and leveraging the IHostingEnvironment service, developers can ensure that the correct settings are applied for each environment. The order of configuration sources is crucial, as settings from a later source will override earlier ones if they exist in multiple locations. This system ensures that the correct configurations are loaded and applied automatically, streamlining the development and deployment process.

Opinions

The use of configuration builder in .NET is highly beneficial for developers, as it reduces the need to manually adjust code for different environments.
The precedence of configuration sources is a key factor in the .NET configuration system, with the last source specified taking precedence in the event of duplicate settings.
The process of loading configurations based on the environment name ({hostEnvironment.EnvironmentName}) is considered a best practice, promoting a more automated and error-proof approach to configuration management.
The importance of the launchSetting.json file is highlighted as a central location for defining environment-specific settings, which can be easily managed and deployed.

How .NET Load Environment Specific Configuration

Now, many times the developers need to work in different environments, such as schema, staging, release, QA, and production. When we test or debug on code in a specific environment, we usually need to modify some code to connect to the different environments like the database connection string or signal settings, etc. To make the developers’ life easier, we can the configuration builder provided by .NET to load and use the correct configurations accordingly.

Let’s say we have created two different configuration files schema.json and staging.json , which both have different parameter values.

databaseSettings.json

{
  "configuratin": {
     "connectionString": "default database connection string"
  }
}

databaseSettings.Staging.json

{
  "configuratin": {
     "connectionString": "staging database connection string"
  }
}

Startup.cs

The default configuration is overridden by settings from another source if they are present. The order in which configurations are specified is important. It establishes the precedence with which settings will be applied. For example, if the same setting exists in both the databaseSetting.json and databaseSettings.{hostEnvironment.EnvironmentName} , the value in the env variable will be used.

The golden rule is that the last configuration source specified “wins” if a setting exists in more than one location.

launchSetting.json

Simplest, Configuration is nothing but a collection of key/value pairs. Here we can use the IHostingEnvironment service to get the current environment.