5 ms·

I’m confused as to what you want instead of what Asp.Net core offers. Nothing is forcing you to inject configuration or to use IOptions. In most cases you don’t

I’m confused as to what you want instead of what Asp.Net core offers. Nothing is forcing you to inject configuration or to use IOptions. In most cases you don’t even need to do anything with the configuration builder because that is part of the default of how the host gets setup. You’re configuration should be automatically built from environment vars and appsettings.json. And of course you can always just access environment variables directly if you want to.

mattmanser 6y ago
I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config<Settings>().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here's one (of many) questions asking simple questions on how to access config values in .Net core: https://stackoverflow.com/questions/46940710/getting-value-from-appsettings-json-in-net-core https://stackoverflow.com/questions/46940710/getting-value-f... 280k views! And look at the sheer length of that answer. If you think they succeeded in making a good configuration library, we have very different definitions of success.
- nightski 6y ago
  It would be pretty trivial to implement the Env class you desire abstracting away the DI stuff.
- maybeOneDay 6y ago
  The sheer length of the answer? That's because it shows optional, more advanced ways to get config stuff. Is this so hard? public class AccountController : Controller { private readonly IConfiguration _config; public AccountController(IConfiguration config) { _config = config; } public IActionResult ResetPassword(int userId, string code) { var vm = new ResetPasswordViewModel { PasswordRequiredLength = _config.GetValue<int>( "AppIdentitySettings:Password:RequiredLength"), RequireUppercase = _config.GetValue<bool>( "AppIdentitySettings:Password:RequireUppercase") }; return View(vm); } }
  - mattmanser 6y ago
    Is this supposed to be ironic? Or just unintentionally? "What's hard about [mass of code] compared to [one liner]?"
    - maybeOneDay 6y ago
      The "mass" of code is an API controller, not just a way to get settings. It's an example of config use in real code. There are roughly 4 lines of code to get two variables out of the settings.json. This scales quite nicely - if we needed 8 different variables from settings then it would be 10 lines of code for 8 variables. Sure, it could be done in one line. My point wasn't to say that this is the most terse environmental variable code possible. My point was to say that it's disingenuous to say "look at the sheer length of that answer" as a way to state that the way to get env variables is hugely bloated. It's literally one ctor param and one private variable. If you don't like that for stylistic reasons, that's fine. I understand the argument saying "there should just be a static class with a readonly prop per variable", I just don't think that this particular code is in real terms actually any worse.
  - vonseel 6y ago
    Makes perfect sense to me, even as a mostly-Python developer with very limited experience in .NET/C# or other ecosystems.
- brynjolf 6y ago
  They have that? You can call Configuration manually if you prefer that way. I feel like everyone in this thread is working overtime to justify complaining when there are multiple options to do what you want.
  - mattmanser 6y ago
    I was thinking about this last night, that's actually not at all true. A 'new' C# programmer doesn't. You have to be advanced enough at C# to know you can do that (i.e. not a junior or outsider) It's also not clear how the config works at first glance or the implications of using a POCO on the app lifecycle. An experienced coder will have to ask themselves questions like, if I store the IOptions object, will it automatically update? If I assign the POCO in startup, will it be a single object, or does startup get called for every new request? Or maybe it will get called for every thread? Or maybe if there are no requests for 10 minutes it automatically shuts down?

mattmanser 6y ago

I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config<Settings>().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here's one (of many) questions asking simple questions on how to access config values in .Net core: https://stackoverflow.com/questions/46940710/getting-value-from-appsettings-json-in-net-core https://stackoverflow.com/questions/46940710/getting-value-f... 280k views! And look at the sheer length of that answer. If you think they succeeded in making a good configuration library, we have very different definitions of success.

nightski 6y ago
It would be pretty trivial to implement the Env class you desire abstracting away the DI stuff.
maybeOneDay 6y ago
The sheer length of the answer? That's because it shows optional, more advanced ways to get config stuff. Is this so hard? public class AccountController : Controller { private readonly IConfiguration _config; public AccountController(IConfiguration config) { _config = config; } public IActionResult ResetPassword(int userId, string code) { var vm = new ResetPasswordViewModel { PasswordRequiredLength = _config.GetValue<int>( "AppIdentitySettings:Password:RequiredLength"), RequireUppercase = _config.GetValue<bool>( "AppIdentitySettings:Password:RequireUppercase") }; return View(vm); } }
- mattmanser 6y ago
  Is this supposed to be ironic? Or just unintentionally? "What's hard about [mass of code] compared to [one liner]?"
  - maybeOneDay 6y ago
    The "mass" of code is an API controller, not just a way to get settings. It's an example of config use in real code. There are roughly 4 lines of code to get two variables out of the settings.json. This scales quite nicely - if we needed 8 different variables from settings then it would be 10 lines of code for 8 variables. Sure, it could be done in one line. My point wasn't to say that this is the most terse environmental variable code possible. My point was to say that it's disingenuous to say "look at the sheer length of that answer" as a way to state that the way to get env variables is hugely bloated. It's literally one ctor param and one private variable. If you don't like that for stylistic reasons, that's fine. I understand the argument saying "there should just be a static class with a readonly prop per variable", I just don't think that this particular code is in real terms actually any worse.
- vonseel 6y ago
  Makes perfect sense to me, even as a mostly-Python developer with very limited experience in .NET/C# or other ecosystems.
brynjolf 6y ago
They have that? You can call Configuration manually if you prefer that way. I feel like everyone in this thread is working overtime to justify complaining when there are multiple options to do what you want.
- mattmanser 6y ago
  I was thinking about this last night, that's actually not at all true. A 'new' C# programmer doesn't. You have to be advanced enough at C# to know you can do that (i.e. not a junior or outsider) It's also not clear how the config works at first glance or the implications of using a POCO on the app lifecycle. An experienced coder will have to ask themselves questions like, if I store the IOptions object, will it automatically update? If I assign the POCO in startup, will it be a single object, or does startup get called for every new request? Or maybe it will get called for every thread? Or maybe if there are no requests for 10 minutes it automatically shuts down?