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

"C:\Program Files\WindowsPowerShell\Modules" is missing in PSModulePath for cmd.exe #830

Closed
PashCracken opened this Issue Jun 24, 2016 · 10 comments

Comments

Projects
None yet
3 participants
@PashCracken

PashCracken commented Jun 24, 2016

What You Are Seeing?

Incorrect PSModulePath in Chocolatey 0.9.10.2 and 0.9.10.3 when you run choco from a normal command prompt(not powershell).

"C:\Program Files\WindowsPowerShell\Modules" is missing in PSModulePath

What is Expected?

In chocolatey 0.9.9.12 it used to get the correct PowerShell process environment variable for PSModulePath. This path contains the "C:\Program Files\WindowsPowerShell\Modules" path. Now it only use the Machine wide PSModulePath where "C:\Program Files\WindowsPowerShell\Modules" is missing

How Did You Get This To Happen? (Steps to Reproduce)

  • Install old chocolatey version = 0.9.9.12
  • Create a small PowerShell module named MyModule and place it in the "C:\Program Files\WindowsPowerShell\Modules" directory
  • Create a small chocolatey package named MyPackage and add the following to chocolateyinstall.ps1
    Import-Module MyModule
  • From a normal Command Prompt(not PowerShell) do a choco install MyPackage and verify that it is successfully installed
  • Upgrade chocolatey to version 0.9.10.3
  • From a normal Command Prompt(not PowerShell) do choco install MyPackage -f to force reinstall the package. The installation will now fail with a message like this:
    The specified module 'MyModule' was not loaded because no valid module file was found in any module directory.

Output Log

The chocolatey log does not provide any additional information. I can provide it if you absolutely need it, but the easiest thing is to follow the steps to reproduce this issue.

@PashCracken

This comment has been minimized.

Show comment
Hide comment
@PashCracken

PashCracken Jun 24, 2016

This really is a blocking issue for our adoption of Chocolatey 0.9.10.
I hope it will be fixed very soon

PashCracken commented Jun 24, 2016

This really is a blocking issue for our adoption of Chocolatey 0.9.10.
I hope it will be fixed very soon

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Jun 24, 2016

Member

I think this is the same as #818?

Member

ferventcoder commented Jun 24, 2016

I think this is the same as #818?

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Jun 24, 2016

Member

So wait, this works properly from PowerShell, but not from cmd?

Also, does it work if you use --use-system-powershell?

Member

ferventcoder commented Jun 24, 2016

So wait, this works properly from PowerShell, but not from cmd?

Also, does it work if you use --use-system-powershell?

@PashCracken

This comment has been minimized.

Show comment
Hide comment
@PashCracken

PashCracken Jun 24, 2016

It works from PowerShell, but not from Command Prompt.
The problem is the same with --use-system-powershell. The error message is a bit more verbose, but it's the same problem

So the main issue here is that the environment variables used by a powershell script started from a Command Prompt (via choco install) is using the machine environment setting and not the PowerShell process environment settings and therefor is missing the path

PashCracken commented Jun 24, 2016

It works from PowerShell, but not from Command Prompt.
The problem is the same with --use-system-powershell. The error message is a bit more verbose, but it's the same problem

So the main issue here is that the environment variables used by a powershell script started from a Command Prompt (via choco install) is using the machine environment setting and not the PowerShell process environment settings and therefor is missing the path

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Jun 24, 2016

Member

That's what I was thinking. Interesting that the older versions of choco work appropriately in this case - the behavior of --use-system-powershell is mostly the same. In the logs, do you see Update-SessionEnvironment being used at all?

I wonder if this is #295 more than it is #439

Member

ferventcoder commented Jun 24, 2016

That's what I was thinking. Interesting that the older versions of choco work appropriately in this case - the behavior of --use-system-powershell is mostly the same. In the logs, do you see Update-SessionEnvironment being used at all?

I wonder if this is #295 more than it is #439

@ferventcoder ferventcoder changed the title from "C:\Program Files\WindowsPowerShell\Modules" is missing in PSModulePath to "C:\Program Files\WindowsPowerShell\Modules" is missing in PSModulePath for cmd.exe Jun 24, 2016

@ferventcoder ferventcoder added this to the 0.9.10.4 milestone Jun 24, 2016

@PashCracken

This comment has been minimized.

Show comment
Hide comment
@PashCracken

PashCracken Jun 24, 2016

I've seen #295 in action also for 0.9.9.12. We had to work around that for the cases where we installed chocolatey as part of the script. When installing chocolatey PSModulePath is set back to the machine level setting for that process.
We worked around that with this code:
$currentProcessPSModulePath = [System.Environment]::GetEnvironmentVariable("PSModulePath","Process") if($currentProcessPSModulePath -notlike "*C:\Program Files\WindowsPowerShell\Modules*") { [System.Environment]::SetEnvironmentVariable("PSModulePath", $currentProcessPSModulePath + ";C:\Program Files\WindowsPowerShell\Modules\","Process")

But, this did not affect the Command Prompt after the initial installation. This PSModulePath issue is new. We don't use Update-SessionEnvironment at all. Look at the repro. Only add one line in you chocolateyinstall.ps1
Import-Module SomeModule
and it will fail after upgrade to 0.9.10.x if the module is in the "C:\Program Files\WindowsPowerShell\Modules" directory

PashCracken commented Jun 24, 2016

I've seen #295 in action also for 0.9.9.12. We had to work around that for the cases where we installed chocolatey as part of the script. When installing chocolatey PSModulePath is set back to the machine level setting for that process.
We worked around that with this code:
$currentProcessPSModulePath = [System.Environment]::GetEnvironmentVariable("PSModulePath","Process") if($currentProcessPSModulePath -notlike "*C:\Program Files\WindowsPowerShell\Modules*") { [System.Environment]::SetEnvironmentVariable("PSModulePath", $currentProcessPSModulePath + ";C:\Program Files\WindowsPowerShell\Modules\","Process")

But, this did not affect the Command Prompt after the initial installation. This PSModulePath issue is new. We don't use Update-SessionEnvironment at all. Look at the repro. Only add one line in you chocolateyinstall.ps1
Import-Module SomeModule
and it will fail after upgrade to 0.9.10.x if the module is in the "C:\Program Files\WindowsPowerShell\Modules" directory

@jberezanski

This comment has been minimized.

Show comment
Hide comment
@jberezanski

jberezanski Jun 24, 2016

Member

PSModulePath is at least partially generated dynamically by PowerShell. Some standard locations are not present in registry values at HKLM\System\CurrentControlSet\Control\Session Manager\Environment and HKCU\Environment:

  1. at least since 2.0, powershell.exe prepends $Env:UserProfile\Documents\WindowsPowerShell\Modules to PSModulePath
  2. powershell.exe 4.0+ appends $Env:ProgramFiles\WindowsPowerShell\Modules to PSModulePath (this location did not exist before PowerShell 4)
    Here is a quick gist from a 2012 R2 with PowerShell 4.0.
    Now, the above happens with powershell.exe. A trivial test with hosting System.Management.Automation in a custom process exhibited the same behavior. It would be worth checking what happens when hosting PowerShell inside Chocolatey - perhaps some configuration settings suppress the PSModulePath additions?
Member

jberezanski commented Jun 24, 2016

PSModulePath is at least partially generated dynamically by PowerShell. Some standard locations are not present in registry values at HKLM\System\CurrentControlSet\Control\Session Manager\Environment and HKCU\Environment:

  1. at least since 2.0, powershell.exe prepends $Env:UserProfile\Documents\WindowsPowerShell\Modules to PSModulePath
  2. powershell.exe 4.0+ appends $Env:ProgramFiles\WindowsPowerShell\Modules to PSModulePath (this location did not exist before PowerShell 4)
    Here is a quick gist from a 2012 R2 with PowerShell 4.0.
    Now, the above happens with powershell.exe. A trivial test with hosting System.Management.Automation in a custom process exhibited the same behavior. It would be worth checking what happens when hosting PowerShell inside Chocolatey - perhaps some configuration settings suppress the PSModulePath additions?
@PashCracken

This comment has been minimized.

Show comment
Hide comment
@PashCracken

PashCracken Aug 3, 2016

Any progress on a fix?

PashCracken commented Aug 3, 2016

Any progress on a fix?

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Aug 3, 2016

Member

Was working on this last night, so yes. This week or early next week for new version that will hopefully include this fix.

Member

ferventcoder commented Aug 3, 2016

Was working on this last night, so yes. This week or early next week for new version that will hopefully include this fix.

@ferventcoder ferventcoder self-assigned this Aug 7, 2016

@ferventcoder ferventcoder added 2 - Working and removed 0 - Backlog labels Aug 7, 2016

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Aug 7, 2016

Member

This should be fixed in 0.10.0.

Member

ferventcoder commented Aug 7, 2016

This should be fixed in 0.10.0.

@ferventcoder ferventcoder added 3 - Done and removed 2 - Working labels Aug 7, 2016

ferventcoder added a commit that referenced this issue Aug 10, 2016

(GH-830) Ensure process PSModulePath items
When PowerShell starts up, it sets at least Program Files path and
sometimes the Documents PSModulePath for PowerShell. Ensure those items
are set if they are missing, as they may be missing when running choco
from cmd.exe (but available when running choco from powershell.exe).

ferventcoder added a commit that referenced this issue Aug 10, 2016

Merge branch 'stable'
* stable: (23 commits)
  (GH-897) Fix DISM /all for newer Windows versions
  (maint) bring back in nuspec into solution folders
  (GH-598) Add output directory for choco pack
  (version) bump to 0.10.0
  (doc) update CHANGELOG/nuspec
  (GH-840) Do not set User Environment for SYSTEM
  (GH-840) Set TMP to cacheLocation as well
  (GH-830) Ensure process PSModulePath items
  (GH-112) Relax HTTPS checksum failure
  (maint) move noop run
  (GH-833) Don't set profile under certain conditions
  (doc) update generated docs
  (GH-112) update options for new version
  (GH-112) Checksums / Install Template
  (GH-112) Update parameter documentation
  (GH-112) Require checksums
  (GH-112) Allow Empty Checksums
  (GH-112) Checksum remote files unless checksum
  (GH-112) Allow user passed checksums
  (GH-112) rename checksum files for proper casing
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment