I am aware of this, but like many other, I find the IOptions<T> a bad abstraction.
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.
Options are a very misunderstood abstraction that we have done a poor job explaining. Those blog posts are simplistic and don't explain what you gain and lose by using the options abstraction.
> that we have done a poor job explaining
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.
I don't like it either, but one advantage is that the settings can be live updated when the config files change
The interface just doesn't bother me. I make reasonably good use of the hierarchical config providers including some custom ones. Plus it supports actually being able to live update the config values.
Meh, seems like just an interface to me.
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.