Approaches to Configuration

[edmistond]

Before the project acquires more features and associated configuration values, we should agree on how we want to handle configuration.

Some general thoughts I have on this, colored by the year I spent at my previous job in the team's release manager role and dealing with these pain points:

• Chaotic configurations lacking any enforcement mechanism are stressful for the people deploying and operating the application.
• I've worked in projects with strongly typed configurations backed by FluentValidator - meaning the application won't even start up if you don't provide all mandatory configuration values - and found it to be a successful approach.
• Being able to override configuration with an environment variable is often helpful.

I was going to cite Kyle McMaster's payroll processor project as an example of this but it seems he's not using it there; he and I worked together on those projects with strongly-typed config and payroll-processor is one of my go-to GitHub links when I'm trying to remember how to build approaches we worked on, or when I need an example of them. 😄 I will have to ask him if minimal APIs/etc are pushing people away from that as a best practice, or if it's just because his application doesn't have much in the way of configuration to begin with.

[benrick]

I tend to like strongly typed configuration sections. As the default place for application configuration.

I'm also a fan of validation on that configuration, because you can make it much easier for new people to get set up. FluentValidator is prefect for that.

I like environment variable overrides as well as command line. Those should work out of the box with dotnet, without anything extra.