Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
What is the rationale behind quietly ignoring Environment.SetEnvironmentVariable calls with targets User or Machine on Unix-like platforms? #32685
Persistently updating environment variables is (at least currently) only supported on Windows, which means passing the
Surprisingly, however, doing the latter doesn't cause an exception, but is quietly ignored (an effective no-op).
Even though this behavior is documented, I wonder:
referenced this issue
Oct 8, 2018
changed the title from
What is the rationale behind quietly ignoring Environment.SetEnvironmentVariable with targets User and Machine on Unix-like platforms?
What is the rationale behind quietly ignoring Environment.SetEnvironmentVariable calls with targets User or Machine on Unix-like platforms?
Oct 8, 2018
I see, thanks.
Is the reason for not throwing a PNSE at runtime compatibility with Mono?
Note that not all CoreFx consumers are compiled languages, so calls from PowerShell code, for instance, would not see the compile-time warning. A cmdlet that wraps this API, such as proposed in PowerShell/PowerShell#5340 (comment), is then faced with the following - suboptimal - choices:
It is one of the reasons. Even without Mono in the equation, no-op seemed like the right choice for this one because of it makes more code "just work" (#20147 (comment)). There are other methods like this in the framework that we choose to turn into no-op on non-Windows platforms. The choices for these Windows-specific methods are always sub-optimal. Ideally, they would be in Windows-specific assembly.
Changing the behavior to throw PNSE would be a breaking change.
Understood re breaking change, so I'm closing this.
Sounds like moving such overloads / methods into Windows-specific assemblies is the way to go in the future.
In cases where this is impractical, please reconsider the current "just works" approach, because its proper name should be "doesn't work, but pretends that it does", which I think is more harmful than throwing an exception.
But the method call itself currently doesn't update the process-level variable directly, so wouldn't what you're proposing be a breaking change?
On a side note: It has always struck me as inconvenient that you need a second call just to make the value effective in the current process as well.
Perhaps it's worth consider extending the enumeration with