3 ms·

For the really simple flat case with key / value pairs and no grouping or hierarchies, I would recommend that you still use the .NET configuration to define an

For the really simple flat case with key / value pairs and no grouping or hierarchies, I would recommend that you still use the .NET configuration to define and read the config sources. Then when you need to read a value, inject IConfiguration and call config.GetValue<string>("someKey") or config.GetValue<int>("otherKey") etc. to get values from it in a flat manner. If you do that enough, you might extract common code or but some other class over it for related settings. At which point you might as well declare a DTO and use IOptions<T> However what OP has is a whole 80 line workflow definition. I don't recommend storing that kind of thing in the .NET config system at all. Then if such a large file has sensitive values such as passwords, it will need some find/replace templating system to substitute them from config. e.g. handlebars with "{{somePassword}}" in the file.

osigurdson 1y ago
Yes, agree about using the regular .NET configuration. That was my suggestion a few comments up. I can see why people might want to do something different (i.e. .env) but I wouldn't use that in a .NET project despite how ugly it is. It is ugly but works well. >> If you do that enough, you might extract common code or but some other class over it for related settings. At which point you might as well declare a DTO and use IOptions<T> I think it rarely needs to be that complicated. I overengineered the configuration system for something before and regretted it. People understand GetValue<T>(key) anything else makes them have to think for no reason.