See the bottom section for why this can be problematic. That is, if directories in the value are defined in terms of other environment variables (e.g., %SystemRoot% or %JAVADIR%), the returned value no longer contains these variables, but their current values. It retrieves the expanded environment-variable value from the registry, because that is what Get-ItemProperty and Get-ItemPropertyValue invariably do.The approach in the blog post has another problematic aspect: While this is a proper solution, it invariably incurs a noticeable performance penalty due to the ad hoc-compilation the first time it is run in a session. Workaround by calling the Windows API via an ad hoc-compiled P/Invoke call to SendMessageTimeout() in C#, via Add-Type: ::SetEnvironmentVariable($dummyName, ::value, 'User') # (This will trigger another broadcast, but its performance impact is negligible.) # Now that the dummy variable has served its purpose, remove it again. ::SetEnvironmentVariable($dummyName, 'foo', 'User')
# Set an environment variable by that name, which makes. NET APIs: # Create a random name assumed to be unique # components, forcing a reload of the environment from the registry. Unfortunately, there’s no direct way to do this from PowerShell, but there are workarounds:īrute-force workaround – simple, but visually disruptive and closes all open File Explorer windows: # Kills all explorer.exe processes, which restarts the Windows shell If this message is not sent, future PowerShell sessions (and other applications) won’t see the modification until the next logon / reboot.
Applications launched afterwards then inherit the updated environment. If you modify environment variables directly via the registry – which, unfortunately, is the right way to do it for REG_EXPAND_SZ-based environment variables such as Path – you need to broadcast a WM_SETTINGCHANGE message so that the Windows (GUI) shell (and its components, File Explorer, the taskbar, the desktop, the Start Menu, all provided via explorer.exe processes) is notified of the environment change and reloads its environment variables from the registry. The procedure in the linked blog post is effective in principle, but is missing a crucial piece of information / additional step: See the bottom section for why use of setx.exe should be avoided for updating the Path environment variable. See the middle section for helper function Add-Path
0 kommentar(er)
