Is there any guidance on introducing new environment variables like this? I would expect AppContext / runtimeconfig.json to be a better fit.

The reason I am asking is that we had several instances in the past where a global variable was set in the system and affected our app, resulting in crashes. In that particular case it was some "system optimizer" app turning on the PGO for all .NET apps. I'd really like to avoid situations like that happening again.

Most such knobs have environment variables controlling them, some also have appcontext switches (and a few I think only have appcontext). In this case, they're very much an implementation detail and effectively experimental for now, and appcontext switches are more official, so I stuck with env vars.

In this case, they're very much an implementation detail and effectively experimental for now

That's exactly what worries me. PGO was also very clearly marked as experimental, yet someone decided to turn it on system-wide. That's dangerously easy to do with environment variables and extremely difficult to diagnose for client-side apps deployed to consumer machines. AppContext is local to a specific app and that seems like a better fit for something that's experimental.

There are literally hundreds of environment variables the runtime and libraries look for. I'm not sure why this one would be special. If you're asking that they all be ripped out, that's a much larger discussion.

If you're asking that they all be ripped out, that's a much larger discussion.

I'm not necessarily asking to rip them all out but I think some review may be in order. Some of the variables are documented, some of them are not. Some of them are prefixed with DOTNET_ (or historically COMPlus_) while this one is not. I'd expect some guidance to be present for this.

We literally had an incident where DOTNET_TieredPGO=1 was set globally by a 3rd-party app and caused crashes of our app once the tiered PGO triggered in one specific code path. It took us months to find the root cause, so forgive me for being cautious about adding more of these global knobs that could accidentally create a problem.

Yes, environment variables can break apps, it has been the case since .NET Framework 1.0. It is both convenient and dangerous.

Yes, environment variables can break apps, it has been the case since .NET Framework 1.0. It is both convenient and dangerous.

AppContext exists since .NET Core 1.0, and it's app local, which is why I think it's a better fit for knobs like these. If you want to stick to environment variables (to my great dismay) it would be nice to follow a convention, like the DOTNET_/ComPlus_ prefix so we can collect the relevant subset into crash reports (eg. as additional parameters into Sentry).