ASP.NET Core configuration system: Isn't the default configuration prone to naming conflicts in environment variables?

Question

I'm trying to wrap my head around the ASP.NET Core Configuration system.

If I understand the default configuration correctly, non-prefixed environment variables will override appsettings.json entries.

For example, if

1. I have an appSettings.json file like this

   {
     "SmtpServer": "myserver.example.com"
   }
   

2. and some other, completely unrelated application running on the same server happens to (globally) set an environment variable called SmtpServer to someotherserver.example.com

that environment variable will override my application configuration.

Now, obviously, I could work around this by (1) prefixing all my settings with the name of my app (which will create a lot of noise in my appsettings.json) or (2) use my own WebApplicationBuilder (2a) to override to default priority order or (2b) to only include environment variables with a specific prefix or (3) blame the other application for setting a global environment variable with such a generic name.

Still, the ASP.NET Core designers are smart people, and if they implement default values, they usually have a very good reason for doing so.

What am I missing? Did I find a flaw in the ASP.NET Core Configuration system default configuration [sic, no pun intended], or is this, for some reason, not a problem in real-life systems? If the latter, what is that reason?

Answer 1

Yes you are correct.

I think the thing you are missing is that usually .net apps are server side websites, APIs and services. In these cases, we only want to run one app on any given "machine", which will be a container or a VM. So there is no real worry about name collision and having the env variables automatically overwrite config is super useful because I have ten different environments, dev, test, staging, live etc to deploy to and I don't want to check the passwords into source control.

If you are writing an app which you install on a clients machine, where you might expect all sorts of other programs to be running, then yes. I would either not use the environment vars at all, or be careful with my appsettings structure.