Because JSON is the standard nowadays, we should stick with the JSON provider and enable the reloading of the configuration upon changes. We should add the common file first, and then optional overrides for each of the different environments (beware the order in which you add each source). We learned how the default configuration of ASP.NET Core already loads JSON files, including different ones for the different environments.
We then saw how to use configuration sections to better organize the settings, and we also looked at using POCO wrappers for them.
So, this made us ponder whether we should use IOptions<T> or our own POCO classes to inject configuration values. Well, if you don't want to pollute your classes or assemblies with references to .NET Core configuration packages, you should stick to your POCO classes. We're not too worried about this, so we recommend keeping the interface wrappers.
We will use IOptionsSnapshot<T> instead of IOptions<T> so that we always get the latest version of the configuration settings.
After this, we looked at feature toggling, to quickly enable or disable features that are just on or off.
In this chapter, we saw the many ways in which we can provide configuration to an ASP.NET Core application. We learned how to build a simple provider that takes configuration from the Windows Registry. We then discussed the many ways in which we can inject configuration settings using the built-in dependency injection framework, and how to be notified of changes in the configuration sources.