Asp.Net Core Reading Configuration Values Complete Guide

ASP.NET Core Reading Configuration Values: A Detailed Explanation with Important Info

Configuration Providers

Configuration providers in ASP.NET Core are responsible for providing configuration values from various sources:

1. File-based Providers

   • JSON Configuration Provider:

     • Stores configurations in JSON files.
     • Typically used for appsettings.json.
     • Supports hierarchical keys using colon (:) or double underscore (__) conventions.
     • Example usage in Program.cs:

       var builder = WebApplication.CreateBuilder(args);
       builder.Configuration.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);
       

   • XML Configuration Provider:

     • Utilizes XML files for configuration.
     • Useful when transitioning projects from earlier versions of ASP.NET where XML was traditionally used.
     • Adds complexity due to the verbosity of XML.
     • Example:

       builder.Configuration.AddXmlFile("config.xml", optional: false, reloadOnChange: true);
       

   • INI Configuration Provider:

     • Supports INI files, a simple format that was common in early Windows application settings.
     • Generally less used today in favor of more modern formats like JSON.
     • Example:

       builder.Configuration.AddIniFile("config.ini", optional: true, reloadOnChange: true);
       

2. Environment Variables Provider:

   • Allows reading configuration from environment variables at runtime.
   • Ideal for secrets (e.g., API keys) and settings that should not be hardcoded into configuration files.
   • Environment variable names are typically in uppercase with double underscores (__) separating nested keys.
   • Example:

     builder.Configuration.AddEnvironmentVariables();
     

3. Command-line Arguments Provider:

   • Enables configuration via command-line arguments during application startup.
   • Commonly used for passing dynamic settings or overriding other configurations.
   • Command-line argument names follow the --key:value convention.
   • Example:

     builder.Configuration.AddCommandLine(args);
     

4. Memory Configuration Provider:

   • Used to provide in-memory settings programmatically.
   • Often useful for testing scenarios or when you need to set default values.
   • Can be initialized with a dictionary of key-value pairs.
   • Example:

     builder.Configuration.AddInMemoryCollection(new Dictionary<string, string>
     {
         { "Key", "Value" },
         { "Section:Key", "Section Value" }
     });
     

5. Custom Providers:

   • Developers can create custom configuration providers to integrate with other data stores.
   • Useful when existing providers do not meet your requirements.
   • Custom providers derive from the abstract ConfigurationProvider class.

Hierarchical Keys and Access Patterns

• Delimiter Format: Use colons (:) for separating nested keys in hierarchical configurations.

  • For example, the following JSON configuration:

    {
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      }
    }
    

  • Can be accessed in code as follows:

    var LogLevelDefault = builder.Configuration["Logging:LogLevel:Default"];
    var LogLevelMicrosoftAspNetCore = builder.Configuration["Logging:LogLevel:Microsoft.AspNetCore"];
    

• Double Underscore Format: As an alternative to colons, use double underscores (__) to specify hierarchical keys.

  • This is particularly useful when configuring settings through environment variables.
  • Example:

    Logging__LogLevel__Default
    

Bindings and Options Pattern

• Binding Configuration: Configuration sections can be bound directly to properties on classes using Bind.

  • This helps in organizing configuration into logical groups represented by objects.
  • Example:

    public class MySettings
    {
        public string KeyOne { get; set; }
        public int KeyTwo { get; set; }
    }
    
    var mySettings = new MySettings();
    builder.Configuration.GetSection("MySettings").Bind(mySettings);
    

• Options Pattern: Simplifies and enhances configuration management by using IOption<T> or IOptionsMonitor<T>.

  • Options pattern promotes loose coupling between configuration and classes that depend on it.
  • Example:
    • Define a settings class:

      public class MySettings
      {
          public string KeyOne { get; set; }
          public int KeyTwo { get; set; }
      }
      

    • Register and bind the settings in ConfigureServices:

      services.Configure<MySettings>(builder.Configuration.GetSection("MySettings"));
      

    • Inject the options as a service in your controllers:

      private readonly IOptionsSnapshot<MySettings> _options;
      
      public HomeController(IOptionsSnapshot<MySettings> options)
      {
          _options = options;
      }
      
      public IActionResult Index()
      {
          return Content($"KeyOne: {_options.Value.KeyOne}, KeyTwo: {_options.Value.KeyTwo}");
      }
      

Built-in Framework Settings

ASP.NET Core reads several built-in settings from appsettings.json or other configuration providers automatically:

• Connection Strings: Stored in ConnectionStrings section.

  • Can be accessed via IConfiguration.GetConnectionString(string name).
  • Example appsettings.json:

    {
      "ConnectionStrings": {
        "DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=TestDb;Trusted_Connection=True;"
      }
    }
    

  • Example access in C#:

    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection"));
    

• Logging Configurations: Defined under Logging section.

  • Configure loggers, levels, providers, etc.
  • Example appsettings.json:

    {
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      }
    }
    

• Application-Specific Settings: Developers can place custom settings under any desired section.

  • Best practice is to use clear, meaningful section names corresponding to their purpose.

Best Practices

• Configuration Precedence: Understand the order in which configuration providers are registered; later providers override previous ones.
• Optional and Reloadable Configurations: Always mark configuration files as optional if they might not exist, handle missing files gracefully.
• Environment-Specific Configurations: Use appsettings.{Environment}.json (like appsettings.Development.json, appsettings.Production.json) for setting specific to different deployment environments.
• Security Considerations: Avoid storing sensitive information like passwords or API keys in plain text configuration files.
• Use Options Pattern: Leverage the options pattern to keep configuration separate from business logic, making code cleaner and easier to maintain.