This feature is added in the `config.AddEnvironmentVariables()` line, which is already included in the default host builder. The latest releases use very good conventions and include a lot of the typical functionality. I recommend reading the docs to avoid redoing what's already there: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/co...
The .net core configuration mechanism has a hierarchy of providers it reads from, one of which is environment variables, and strongly typed configuration is supported out of the box, so you're exact use case is supported natively by it.
This blog has similar thoughts: https://rimdev.io/strongly-typed-configuration-settings-in-a...
or this blog: https://adamstorr.azurewebsites.net/blog/beyond-basics-aspne...
Or simply google 'asp net strongly typed configuration' and notice everyone seems to be reaching similar conclusions and building their own things.
Just load the setting yourself and register it as a singleton.
Yes, indeed you have. I've tried to both skim and read the "introductory" documentation for `Options<T>` and the only gain I could figure out is monitoring + refresh. I still have no idea how to use it though, so I don't.
Meh, seems like just an interface to me.
Why would you prefer that, to the the built-in classes to load settings via good old environment variables, among other sources? Which do you think new people coming to your team would prefer to see?
I seriously don't understand how MS managed to make loading some configs so outrageously confusing.
Every time I have to write in .net and I'm forced to go down this path, I've got to go back to the one project where it worked, and copy code across and install dependencies until the whole thing decides it's finally happy.
Bonus Points, by loading all settings at once into strongly typed properties at startup, it will fail fast if a setting is missing, which to me is a benefit.
But I still pass this class via DI to the controllers for testability reasons. If you are using ASP Net, just do things the asp-net way for the sake of other people who have to inherit the code.
Outside of AspNet I never use any automatic DI.