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

[PashCracken]

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 really is a blocking issue for our adoption of Chocolatey 0.9.10.
I hope it will be fixed very soon

[ferventcoder]

I think this is the same as #818?

[ferventcoder]

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

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

[PashCracken]

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]

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

[PashCracken]

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]

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]

Any progress on a fix?

[ferventcoder]

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

[ferventcoder]

This should be fixed in 0.10.0.