3 ms·

Actually I think .NET config is pretty good. You define a file, which can be overridden by environment variables which in turn can be overridden by command line

Actually I think .NET config is pretty good. You define a file, which can be overridden by environment variables which in turn can be overridden by command line parameters. Just reading environment variables is fine as well but then you have to do source .env before you run anything (unless you are talking about Python like approach where .env is just another config file essentially).

giancarlostoro 1y ago
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.
SideburnsOfDoom 1y ago
> Actually I think .NET config is pretty good. You define a file, which can be overridden by environment variables Agreed that it's good. Partly because it's even more flexible than that. There are good defaults, but you decide which sources in which order are use. e.g. in our case it is appsettings.json appsettings.{env}.json (e.g. appsettings.dev.json ) Environment variables There are also providers for places where secrets are stored, such as Azure Key vault (1), which would be layered on last. And a test provider where you just supply some key-value pairs from code (2). Or roll your own (3). 1) https://learn.microsoft.com/en-us/aspnet/core/security/key-vault-configuration https://learn.microsoft.com/en-us/aspnet/core/security/key-v... 2) https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration-providers#memory-configuration-provider https://learn.microsoft.com/en-us/dotnet/core/extensions/con... 3) https://vinayakabhat.medium.com/integrating-aws-secrets-manager-with-asp-net-core-a-secure-way-to-manage-secrets-cd6f95469dd9 https://vinayakabhat.medium.com/integrating-aws-secrets-mana...

giancarlostoro 1y ago

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.

SideburnsOfDoom 1y ago

> Actually I think .NET config is pretty good. You define a file, which can be overridden by environment variables Agreed that it's good. Partly because it's even more flexible than that. There are good defaults, but you decide which sources in which order are use. e.g. in our case it is appsettings.json appsettings.{env}.json (e.g. appsettings.dev.json ) Environment variables There are also providers for places where secrets are stored, such as Azure Key vault (1), which would be layered on last. And a test provider where you just supply some key-value pairs from code (2). Or roll your own (3). 1) https://learn.microsoft.com/en-us/aspnet/core/security/key-vault-configuration https://learn.microsoft.com/en-us/aspnet/core/security/key-v... 2) https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration-providers#memory-configuration-provider https://learn.microsoft.com/en-us/dotnet/core/extensions/con... 3) https://vinayakabhat.medium.com/integrating-aws-secrets-manager-with-asp-net-core-a-secure-way-to-manage-secrets-cd6f95469dd9 https://vinayakabhat.medium.com/integrating-aws-secrets-mana...