5 ms·

I agree. The first thing I always do is make a custom Settings class which just loads settings via good old `Environment.GetEnvironmentVariable`. Super simple a

I agree. The first thing I always do is make a custom Settings class which just loads settings via good old `Environment.GetEnvironmentVariable`. Super simple and never failed me. 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.

nullsense 6y ago
>I agree. The first thing I always do is make a custom Settings class which just loads settings via good old `Environment.GetEnvironmentVariable`. Super simple and never failed 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.
- 0xcoffee 6y ago
  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-asp-net-core-part-ii/ https://rimdev.io/strongly-typed-configuration-settings-in-a... or this blog: https://adamstorr.azurewebsites.net/blog/beyond-basics-aspnetcore-adding-and-using-configuration 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.
  - macca321 6y ago
    I don't like it either, but one advantage is that the settings can be live updated when the config files change
  - oaiey 6y ago
    Do not use Options. Use regular poco bound against Configuration sections like the rest of us :)
  - nullsense 6y ago
    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.
  - davidfowl 6y ago
    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.
    - zvrba 6y ago
      > 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.
manigandham 6y ago
ASP.NET supports environment variables and uses them by default (that's how the dev/prod environment context is set). 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/configuration/?view=aspnetcore-5.0 https://docs.microsoft.com/en-us/aspnet/core/fundamentals/co...
SideburnsOfDoom 6y ago
> make a custom Settings class class which just loads settings via good old `Environment.GetEnvironmentVariable 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?
- FridgeSeal 6y ago
  Because the morass that is HostSetting/HostedServices/etc and friends is a confusing tangle of dependencies (some unspecified) bizarre calls that you've missed and general confusion. 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.

nullsense 6y ago

>I agree. The first thing I always do is make a custom Settings class which just loads settings via good old `Environment.GetEnvironmentVariable`. Super simple and never failed 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.

0xcoffee 6y ago
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-asp-net-core-part-ii/ https://rimdev.io/strongly-typed-configuration-settings-in-a... or this blog: https://adamstorr.azurewebsites.net/blog/beyond-basics-aspnetcore-adding-and-using-configuration 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.
- macca321 6y ago
  I don't like it either, but one advantage is that the settings can be live updated when the config files change
- oaiey 6y ago
  Do not use Options. Use regular poco bound against Configuration sections like the rest of us :)
- nullsense 6y ago
  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.
- davidfowl 6y ago
  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.
  - zvrba 6y ago
    > 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.

manigandham 6y ago

ASP.NET supports environment variables and uses them by default (that's how the dev/prod environment context is set). 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/configuration/?view=aspnetcore-5.0 https://docs.microsoft.com/en-us/aspnet/core/fundamentals/co...

SideburnsOfDoom 6y ago

> make a custom Settings class class which just loads settings via good old `Environment.GetEnvironmentVariable 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?

FridgeSeal 6y ago
Because the morass that is HostSetting/HostedServices/etc and friends is a confusing tangle of dependencies (some unspecified) bizarre calls that you've missed and general confusion. 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.