2 ms·

I'm not saying its bad, I'm just saying nobody is consistent in strategy and it frustrates me. Yeah I'm on about how .env can just be a file. https://www.nuget

I'm not saying its bad, I'm just saying nobody is consistent in strategy and it frustrates me. Yeah I'm on about how .env can just be a file. https://www.nuget.org/packages/dotenv.net https://www.nuget.org/packages/dotenv.net

osigurdson 1y ago
By strategy, do you mean, the various hierarchies that people use? If so, I agree that sticking to a flat set of key / value pairs is usually fine. A little resistance to hierarchy is generally a good thing in software.
- SideburnsOfDoom 1y ago
  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.

osigurdson 1y ago

By strategy, do you mean, the various hierarchies that people use? If so, I agree that sticking to a flat set of key / value pairs is usually fine. A little resistance to hierarchy is generally a good thing in software.

SideburnsOfDoom 1y ago
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.