Before you begin: Join our book community on Discord
Give your feedback straight to the author himself and chat to other early readers on our Discord server (find the “architecting-aspnet-core-apps-3e” channel under EARLY ACCESS SUBSCRIPTION).
https://packt.link/EarlyAccess
This chapter covers the .NET Options pattern, a building block of any application. .NET Core introduced new predefined mechanisms to enhance the usage of application settings available to ASP.NET Core applications. These allow us to divide our configuration into multiple smaller objects, configure them during various stages of the startup flow, validate them, and even watch for runtime changes with minimal effort.
The new options system repurposed the ConfigurationManager class as an internal piece. We no longer can use it as the old .NET Framework-era static methods are gone. The new patterns and mechanisms help avoid useless coupling, add flexibility to our designs, and are DI-native. The system is also simpler to extend.
The Options pattern goal is to use settings at runtime, allowing changes to the application to happen without changing the code. The settings could be as simple as a string, a bool, a database connection string, or a complex object that holds an entire subsystem’s configuration.This chapter delves into various tools and methodologies we can use for managing, injecting, and loading configurations and options into our ASP.NET Core applications. Our journey spans a broad spectrum of scenarios, covering everything from commonly encountered to more complex use cases.At the end of the chapter, you will know how to leverage the .NET options and settings infrastructure.In this chapter, we cover the following topics:
- Loading the configuration
- Learning the building blocks
- Exploring common usage scenarios
- Learning options configuration
- Validating our options objects
- Validating options using FluentValidation
- Injecting options objects directly—a workaround
- Centralizing the configuration for easier management
- Using the configuration-binding source generator
- Using the options validation source generator
- Using the options validation source generator
Let’s get started!
Loading the configuration
ASP.NET Core allows us to load settings from multiple sources seamlessly. We can customize these sources from the WebApplicationBuilder, or use the defaults set by calling the WebApplication.CreateBuilder(args) method.The default sources, in order, are as follows:
- appsettings.json
- appsettings.{Environment}.json
- User secrets; these are only loaded when the environment is Development
- Environment variables
- Command-line arguments
The order is essential, as the last to be loaded overrides previous values. For example, you can set a value in appsettings.json and override it in appsettings.Staging.json by redefining the value in that file, user secrets, an environment variable or by passing it as a command-line argument when you run your application.
You can name your environments as you want, but by default, ASP.NET Core has built-in helper methods for Development, Staging, and Production.
On top of the default providers, we can register other configuration sources out of the box, like AddIniFile, AddInMemoryCollection, and AddXmlFile, for example. We can also load NuGet packages to install custom providers, like Azure KeyVault and Azure App Configuration, to centralize secrets and configuration management into the Azure cloud. The most interesting part of those configuration providers is that no matter the sources, it does not affect the consumption of the settings, only the composition root. This means we can start loading settings one way, then change our mind later or have different strategies for dev and prod, and none of that affects the codebase but the composition root.We explore a few building blocks next.
