The options pattern uses classes to represent groups of related settings. Options also provide a mechanism to validate configuration data. It was introduced with .NET Core. It gives you a nice separation of concerns and it adheres to the Interface Segregation Principle (ISP).
Validate strongly typed options when using config sections
I like to validate my application configuration upon startup. Especially when doing local development, I want to know which application settings are missing. I also like to know where I should add them. This blog shows how to implement validation of your configuration classes using data annotations.
Dictionary-style settings as IOptions
I love how we can use appsettings.json files to configure applications in the .NET Core platform. The JSON-format feels a lot less bloated than the old XML appSettings config I used to work with. In this blog I’ll explore how to load a dictionary-style settings class as an IOption. This can be very useful when working with dependency injection.
Setup multiple appsetting-files with a .NET Console Application
In ASP.NET Core we are used to have multiple appsettings.json files with settings that differ per environment. I want to do the same in a Console Application. This makes debugging the application easier.
Dependency injection (with IOptions) in Console Apps in .NET Core
When you are used to building web applications, you kind of get hooked to the ease of Dependency Injection (DI) and the way settings can be specified in a JSON file and accessed through DI (IOptions