Modern .NET Core applications rely heavily on configuration files, and appsettings.json plays a crucial role in managing application settings. Understanding how to effectively retrieve and utilize these settings is essential for building flexible and maintainable applications. This comprehensive guide delves into various techniques for accessing values from your appsettings.json file, covering best practices and advanced scenarios to empower you with the knowledge to efficiently manage your .NET Core application’s configuration. From basic retrieval methods to handling complex data structures, we’ll explore the full spectrum of working with appsettings.json.

Basic Configuration Retrieval

At its core, retrieving values from appsettings.json involves using the IConfiguration interface. This interface provides methods like GetValue<T>() to access specific settings. For instance, retrieving a database connection string might look like this:

string connectionString = _configuration.GetValue<string>("ConnectionStrings:DefaultConnection");

This method is straightforward for simple values. However, as your configuration grows, managing individual settings this way can become cumbersome. For more structured access, the GetSection() method becomes invaluable.

Using the Options Pattern

The Options pattern provides a more structured and type-safe way to access configuration settings. By creating classes that mirror the structure of your appsettings.json sections, you can bind configuration values directly to strongly-typed objects. This approach not only improves code readability but also enhances maintainability by leveraging compile-time type checking.

For example, consider a “MailSettings” section in your appsettings.json. You could define a corresponding MailSettings class and bind the configuration to an instance of this class:

services.Configure<MailSettings>(_configuration.GetSection("MailSettings")); 

This approach allows you to access settings via properties of the MailSettings object, making your code cleaner and less prone to errors.

Handling Complex Data Structures

appsettings.json isn’t limited to simple key-value pairs. You can define arrays and nested objects within your configuration. The Options pattern seamlessly handles these complex structures. By defining corresponding classes with collections or nested properties, you can map your configuration to these complex objects with ease.

Imagine configuring a list of server URLs. You can define a class with a list property and then bind the configuration:

public class ServerSettings { public List<string> Urls { get; set; } } 

This allows you to access the server URLs through the Urls property of the ServerSettings object after configuration binding.

Environment-Specific Configuration

.NET Core allows for environment-specific configuration files like appsettings.Development.json. These files override the default appsettings.json for specific environments, allowing you to tailor settings for development, staging, or production. The configuration system automatically loads the appropriate file based on the current environment.

This mechanism simplifies environment-specific customizations without modifying the base configuration file, streamlining deployment processes and minimizing the risk of configuration errors across environments.

• Use the Options pattern for type-safe and structured configuration access.
• Leverage environment-specific configuration files to manage settings across different environments.

As stated by David Fowler, Principal Software Engineer at Microsoft, “Configuration should be easy to manage and access, promoting code clarity and maintainability.” This principle underscores the importance of efficient configuration management in .NET Core applications.

1. Define a class that represents your configuration structure.
2. Use services.Configure<T>() to bind the relevant configuration section to your class.
3. Inject an instance of IOptions<T> into your classes to access the configured values.

Featured Snippet: The Options pattern in .NET Core provides a strongly-typed approach to accessing application settings, enhancing code maintainability and reducing configuration errors. It simplifies working with complex configuration structures by mapping settings to objects.

Learn more about .NET Configuration- Configuration in ASP.NET Core: Microsoft Documentation

• Options pattern in .NET: Microsoft Documentation on Options
• Configuration Best Practices: Configuration Best Practices

[Infographic Placeholder: Visual representation of configuration binding using the Options pattern.]

FAQ

Q: What are the benefits of using the Options pattern over direct access via IConfiguration?

A: The Options pattern offers strong typing, improved code readability, and better maintainability. It simplifies working with complex data structures within the configuration file.

By implementing these strategies, you’ll harness the full potential of appsettings.json, creating robust and adaptable .NET Core applications. Remember that effective configuration management is key to building maintainable and scalable software. Explore the provided resources to further enhance your understanding and delve deeper into advanced configuration techniques. Start optimizing your .NET Core configuration management today!

Question & Answer :
I am not sure what am I missing here, but I am not able to get the values from my appsettings.json in my .NET Core application. I have my appsettings.json as:

{ "AppSettings": { "Version": "One" } } 

Startup:

public class Startup { private IConfigurationRoot _configuration; public Startup(IHostingEnvironment env) { _configuration = new ConfigurationBuilder() } public void ConfigureServices(IServiceCollection services) { //Here I setup to read appsettings services.Configure<AppSettings>(_configuration.GetSection("AppSettings")); } } 

Model:

public class AppSettings { public string Version{ get; set; } } 

Controller:

public class HomeController : Controller { private readonly AppSettings _mySettings; public HomeController(IOptions<AppSettings> settings) { //This is always null _mySettings = settings.Value; } } 

_mySettings is always null. Is there something that I am missing here?

Program and Startup class

ASP.NET Core 6.x

ASP.NET Core 6.x brings another big changes in the Program class:

• No Program.Main() boilerplate if you select to use Top level statements
• Implicit using directives
• No Startup class as everything is in Program file
• Introduce WebApplication and WebApplicationBuilder

Some said these changes are good for new comers to learn ASP.NET Core. I kind of felt the other way around. I think the separation of Program and Startup made more sense, at least to me.

Anyway…

This is how Program.cs would look like:

// Program.cs public class Program { public static void Main(string[] args) { var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllersWithViews(); var app = builder.Build(); if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler("/errors"); app.UseHsts(); } app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); app.MapControllerRoute( name: "areaRoute", pattern: "{area:exists}/{controller=home}/{action=index}/{id?}"); app.MapControllerRoute( name: "default", pattern: "{controller=home}/{action=index}/{id?}"); app.Run(); } } 

You can kind of tell the section between WebApplication.CreateBuilder() and builder.Build() is what the old ConfigureServices(IServiceCollection services) used to do. And the section before app.Run() is what the old Configure() from Startup used to do.

Most importantly, IConfiguration is injected to the pipeline so you can use it on your controllers.

ASP.NET Core 3.x to 5

ASP.NET Core 3.x brings some changes that try to support other approaches such as worker services, so it replaces web host with a more generic host builder:

// Program.cs public class Program { public static void Main(string[] args) { CreateHostBuilder(args).Build().Run(); } public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); }; } } 

The Startup class looks pretty similar to the 2.x version though.

ASP.NET Core 2.x

You don’t need to new IConfiguration in the Startup constructor. Its implementation will be injected by the DI system.

// Program.cs public class Program { public static void Main(string[] args) { BuildWebHost(args).Run(); } public static IWebHost BuildWebHost(string[] args) => WebHost.CreateDefaultBuilder(args) .UseStartup<Startup>() .Build(); } // Startup.cs public class Startup { public IHostingEnvironment HostingEnvironment { get; private set; } public IConfiguration Configuration { get; private set; } public Startup(IConfiguration configuration, IHostingEnvironment env) { this.HostingEnvironment = env; this.Configuration = configuration; } } 

ASP.NET Core 1.x

You need to tell Startup to load the appsettings files.

// Program.cs public class Program { public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseStartup<Startup>() .UseApplicationInsights() .Build(); host.Run(); } } //Startup.cs public class Startup { public IConfigurationRoot Configuration { get; private set; } public Startup(IHostingEnvironment env) { var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true) .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true) .AddEnvironmentVariables(); this.Configuration = builder.Build(); } ... } 

Getting Values

There are many ways you can get the value you configure from the app settings:

• Simple way using ConfigurationBuilder.GetValue<T>
• Using Options Pattern

Let’s say your appsettings.json looks like this:

{ "ConnectionStrings": { ... }, "AppIdentitySettings": { "User": { "RequireUniqueEmail": true }, "Password": { "RequiredLength": 6, "RequireLowercase": true, "RequireUppercase": true, "RequireDigit": true, "RequireNonAlphanumeric": true }, "Lockout": { "AllowedForNewUsers": true, "DefaultLockoutTimeSpanInMins": 30, "MaxFailedAccessAttempts": 5 } }, "Recaptcha": { ... }, ... } 

Simple Way

You can inject the whole configuration into the constructor of your controller/class (via IConfiguration) and get the value you want with a specified key:

public class AccountController : Controller { private readonly IConfiguration _config; public AccountController(IConfiguration config) { _config = config; } [AllowAnonymous] public IActionResult ResetPassword(int userId, string code) { var vm = new ResetPasswordViewModel { PasswordRequiredLength = _config.GetValue<int>( "AppIdentitySettings:Password:RequiredLength"), RequireUppercase = _config.GetValue<bool>( "AppIdentitySettings:Password:RequireUppercase") }; return View(vm); } } 

Options Pattern

The ConfigurationBuilder.GetValue<T> works great if you only need one or two values from the app settings. But if you want to get multiple values from the app settings, or you don’t want to hard code those key strings in multiple places, it might be easier to use Options Pattern. The options pattern uses classes to represent the hierarchy/structure.

To use options pattern:

1. Define classes to represent the structure
2. Register the configuration instance which those classes bind against
3. Inject IOptions<T> into the constructor of the controller/class you want to get values on

1. Define configuration classes to represent the structure

You can define classes with properties that need to exactly match the keys in your app settings. The name of the class does’t have to match the name of the section in the app settings:

public class AppIdentitySettings { public UserSettings User { get; set; } public PasswordSettings Password { get; set; } public LockoutSettings Lockout { get; set; } } public class UserSettings { public bool RequireUniqueEmail { get; set; } } public class PasswordSettings { public int RequiredLength { get; set; } public bool RequireLowercase { get; set; } public bool RequireUppercase { get; set; } public bool RequireDigit { get; set; } public bool RequireNonAlphanumeric { get; set; } } public class LockoutSettings { public bool AllowedForNewUsers { get; set; } public int DefaultLockoutTimeSpanInMins { get; set; } public int MaxFailedAccessAttempts { get; set; } } 

2. Register the configuration instance

And then you need to register this configuration instance in ConfigureServices() in the start up:

using Microsoft.Extensions.Configuration; using Microsoft.Extensions.DependencyInjection; ... namespace DL.SO.UI.Web { public class Startup { ... public void ConfigureServices(IServiceCollection services) { ... var identitySettingsSection = _configuration.GetSection("AppIdentitySettings"); services.Configure<AppIdentitySettings>(identitySettingsSection); ... } ... } } 

Note: if you’re not seeing the overload extension method of service.Configure<> that takes IConfiguration as parameter, you probably need to install Microsoft.Extensions.Options.ConfigurationExtensions NuGet package.

For ASP.NET Core 6.x

Due to the changes I mentioned at the beginning for ASP.NET Core 6.x, you would need to bind the section and add it to the DI in the following:

// Program.cs public class Program { public static void Main(string[] args) { var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllersWithViews(); builder.Services.Configure<AppIdentitySettings>( builder.Configuration.GetSection("AppIdentitySettings") ); var app = builder.Build(); ... app.Run(); } } 

You can read more about this here.

3. Inject IOptions

Lastly on the controller/class you want to get the values, you need to inject IOptions<AppIdentitySettings> through constructor:

public class AccountController : Controller { private readonly AppIdentitySettings _appIdentitySettings; public AccountController(IOptions<AppIdentitySettings> appIdentitySettingsAccessor) { _appIdentitySettings = appIdentitySettingsAccessor.Value; } [AllowAnonymous] public IActionResult ResetPassword(int userId, string code) { var vm = new ResetPasswordViewModel { PasswordRequiredLength = _appIdentitySettings.Password.RequiredLength, RequireUppercase = _appIdentitySettings.Password.RequireUppercase }; return View(vm); } }