Env.Config("Settings:MyEasyValue");

    Env.Config<Settings>().MySuperEasyTypedValue;

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-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.

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);
        }
    }

"What's hard about [mass of code] compared to [one liner]?"

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.

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?