Configuration - Nano-Core/Nano.Library GitHub Wiki

Table of Contents


Summary

The configuration follows the regular .Net Core pattern, populating key/values from a configuration provider. Nano defaults to use appsettings.json as provider, but all or individual settings may be overridden from either environmental variables or command-line parameters, as detailed later.

The configuration is divided into several sections, each controlling the behavior of different parts of Nano. The structure and properties of each section corresponds to an {section}Option implementation, and is initialized and populated during application start-up, thus available for later dependency injection, if needed. Most settings comes with a default value, and may be omitted. For improved clarity, it's recommended to include them anyway.

Each section and their variables are described in detail, in Appendix - App Settings.


Environment

By design Nano is environment neutral, and does neither operate with any environment specific configuration, nor has any environment specific behavior. Everything is defined by having different configurations for different environments, like appsettings.{environment}.json.

.Net Core reads the environment variable ASPNETCORE_ENVIRONMENT, and applies the corresponding configuration. The environment defaults to Development. It's recommended to keep the code environment neutral, and handle differences in configuration and in the deployment pipeline.


Override Variables

Configuration variables from appsettings.json may be overridden.

This can be accomplished by parsing command-line arguments or setting environmental variables, having the same path|name as the corresponding variable in the file.

The order of which the different ways of specifying configuration variables is traversed. The later overrides the former.

  1. App Settings
  2. Command-Line Arguments
  3. Environmental Variables
  4. User Secrets (Development environment only)

Custom Sections

Extending the configuration and adding custom sections, obtaining the same registration and behavior as the existing Nano sections, is straight forward.

Nano provides the IServiceCollection extension method .AddOptions<TOption>(...), registering the dependency of a custom configuration section. The TOption generic type paramter, defines the object model, the section will be deserialized into.

Sample Implementation

First, implement an options model.

public class MyOptions
{
    // Properties...
}

Second, add a section to appsetings.json, matching the structure of the options model above.

{
    "MySection": {
    }
}

Last, register the dependency in Program.Main(), passing section name.

.ConfigureServices(x =>
{
    x.AddConfigOptions<MyOptions>("mySection");
})

Injected Services

When building the configuration, dependencies related to the different sections as well as any custom sections are configured and initialized.

Dependencies:
  • MyOptions
  • IOptions<MyOptions>

For a full list of services and dependencies, see Injected Dependencies


⚠️ **GitHub.com Fallback** ⚠️