What is the rationale behind quietly ignoring Environment.SetEnvironmentVariable calls with targets User or Machine on Unix-like platforms?

[mklement0]

Persistently updating environment variables is (at least currently) only supported on Windows, which means passing the User and Machine enumeration values to Environment.SetEnvironmentVariable are unsupported on macOS and Linux.

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:

• what the rationale for this behavior is, given that as an API user you generally want to be notified of attempts to use functionality that is unsupported on a given platform.

• whether the behavior can be changed.

[jkotas]

See the discussion in https://github.com/dotnet/corefx/issues/20147

[mklement0]

Thanks, @jkotas.

Reading the discussion and the linked issues I gather that the plan for addressing this is the following, correct?:

• Report a compile-time warning,
• but no runtime PNSE

[jkotas]

Right, that is the current plan.

[mklement0]

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:

• Accept the quiet no-op runtime behavior on unsupported platforms.

• Duplicate the compile-time warnings by turning them into PowerShell errors / warnings.

[jkotas]

Is the reason for not throwing a PNSE at runtime compatibility with Mono?

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" (https://github.com/dotnet/corefx/issues/20147#issuecomment-303501844). 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.

[mklement0]

Thanks, @jkotas.

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.
(A compiler warning, which is helpful irrespective of the runtime behavior, can mitigate this, but those warnings aren't always seen, e.g., in PowerShell).

[danmoseley]

Arguably it could at least update the process environment, since in some cases this would happen on Windows (depends on how many apps respect the WM_SETTINGCHANGE message)

[mklement0]

@danmosemsft:

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 UserAndProcess and MachineAndProcess values that set both the persisted and the current-process value.