New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Environment Variable Changes May Require Reboot #728
Comments
Upgrade to the latest prerelease and let me know if you are still seeing this issue. This is fallout from #724. |
What happens is that the install tries to remove the user environment variable for "ChocolateyInstall" but due to the bug in #724 it was actually creating an empty one. The extension starts failing because it can't find the path to itself anymore. Possibly we need a secondary way for it to validate its location. |
If that is not what you are seeing (the empty environment variable in user), then it's the other fallout from #303 - which is that we need a way to trigger the system to see that the environment variables have updated and it should respond accordingly.
|
Let me know which of the above apply. Thanks! |
I thought I'd checked and was running the latest preview. I'll double check just to be sure. Sent from my Windows Phone From: Rob Reynoldsmailto:notifications@github.com Let me know which of the above apply. Thanks! You are receiving this because you authored the thread. |
I'm using 0.9.10-beta-20160506 with v1.3.0 of chocolatey.extension. I have a 'ChocolateyInstall' environment variable set as a system variable, but nothing as a user variable. |
And when you open a new shell and type If it is empty, call |
Of course this assumes you are seeing the issues still. |
Yes, still seeing that error. $env:ChocolateyInstall gives |
That is strange that you are still seeing this error. Does it persist after reboot? |
I should have what I believe is a fix for this soon. |
Setting environment variables directly in the registry has a side effect of sometimes not letting explorer.exe know that something changed. When that happens, it doesn't matter if you open a new shell or not, the environment variables available to new shells will reflect the older values. The fix for this is a two fold attack - broadcast the change and set another environment variable with SetX. Broadcasting the change using the native method `SendMessageTimeout` has no effect on currently open shells, but helps GUIs and explorer.exe realize that something changed and that they should look to refresh their environment values. SetX.exe also has no effect on the current shell, but it forces explorer.exe to refresh the values that are available. Set a user environment variable with the current date and time. This also has a nice side effect of letting the user know the last time the environment was updated by Chocolatey. If either of these fail, report the error as a warning.
* stable: (doc) update CHANGELOG/nuspec (GH-728) Fix: Env var changes may require reboot (GH-729) Update env after setting env vars for scripts (GH-723) Warn when can't find file (GH-723) Convert msiexec to full path (GH-723) Ensure wusa.exe uses a full path (GH-727) Fix: Name is bad if response has params
This has been released in https://chocolatey.org/packages/chocolatey/0.9.10-beta-20160509 You can upgrade to it with |
Setting environment variables directly in the registry has a side effect of sometimes not letting explorer.exe know that something changed. When that happens, it doesn't matter if you open a new shell or not, the environment variables available to new shells will reflect the older values. The fix for this is a two fold attack - broadcast the change and set another environment variable with SetX. Broadcasting the change using the native method `SendMessageTimeout` has no effect on currently open shells, but helps GUIs and explorer.exe realize that something changed and that they should look to refresh their environment values. SetX.exe also has no effect on the current shell, but it forces explorer.exe to refresh the values that are available. Set a user environment variable with the current date and time. This also has a nice side effect of letting the user know the last time the environment was updated by Chocolatey. If either of these fail, report the error as a warning.
I am getting the same error, just installed chocolatey using an elevated prompt (as suggested) and I get the same error as @flcdrg when running choco from a non-elevated prompt. I'm using Chocolatey 0.10.3 on Windows 10. |
After a reboot it works, but the installation scripts advices to restart any prompt, not to restart the computer: maybe it could be more precise ? |
@warpdesign I'm not sure what you are running into is quite the same. This issue was about trying to use Chocolatey licensed edition with Chocolatey immediately after install. Perhaps you can expand on what you are running into as part of a new issue? Thanks! |
What You Are Seeing?
What is Expected?
How Did You Get This To Happen? (Steps to Reproduce)
Running
choco pack
from non-elevated shell.I don't remember seeing these errors with the previous chocolatey.extension (assuming that is involved)
The text was updated successfully, but these errors were encountered: