Removals from $ENV:PSModulePath are not respected.

[BatmanAMA]

System Details Output

### VSCode version: 1.36.1 2213894ea0415ee8c85c5eea0d0ff81ecc191529 x64

### VSCode extensions:
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]


### PSES version: 1.12.1.0

### PowerShell version:

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.1
PSEdition                      Core
GitCommitId                    7.0.0-preview.1
OS                             Microsoft Windows 10.0.18922
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Background

At my company, we use user documents redirection, causing my powershell user module folder to be located on a network share. In order to avoid issues with PSModule auto-loading, I remove $HOME/documents/WindowsPowershell/Modules from my modulepath and instead add $HOME/WindowsPowershell/Modules and have relocated all my user specific modules there. This isn't respected in vscode.

Expected Behavior

PS > $mydocs = [environment]::GetFolderPath('MyDocuments')
PS > $pattern = [regex]::Escape($mydocs)
PS > $Env:PSModulePath = ($Env:psmodulepath -split ';' | where {$_ -notmatch $pattern}) -join ';'
PS > #Feel free to do whatever you'd like
PS > ($Env:PSmodulepath -split ';' | where {$_ -match $pattern}).count -eq 0
True

Actual Behavior

PS > $mydocs = [environment]::GetFolderPath('MyDocuments')
PS > $pattern = [regex]::Escape($mydocs)
PS > $Env:PSModulePath = ($Env:psmodulepath -split ';' | where {$_ -notmatch $pattern}) -join ';'
PS > #Type into a document with language "PowerShell"
PS > ($Env:PSmodulepath -split ';' | where {$_ -match $pattern}).count -eq 0
False

Attached Logs

logs.zip

[rjmholt]

This is due to PowerShell/PowerShell#9921. PSScriptAnalyzer uses a runspace pool internally (and we do in PSES as well) and that resets the PSModulePath. It will be fixed in PS 7 by PowerShell/PowerShell#10300. We are doing other work on the extension at the moment, but will revisit the way we invoke PSScriptAnalyzer down the track. However, because of the way PSSA also uses a runspace pool, this may not be fixable in Windows PowerShell.

[BatmanAMA]

For anyone else experiencing this issue, I would recommend moving all your modules out of your user profile module path and into a system module path. I had about 130 modules in my user profile resting on a remote file share and it was causing near constant progress bars in VS code, and that is fully gone now that they are all in C:\program files\powershell\modules.

[KirkMunro]

Related: PowerShell PR #10257

[jhoneill]

I seem to have hit this problem. It only affects the integrated console.
Net effects are
1 . Modules installed to ~\.vscode\extensions\ms-vscode.powershell-preview-2019.11.0\modules(plaster and PSScript analyzer) aren't loadable. If I put write-verbose $env:PsmodulePath -verbose in my profile I can see something adds this directory, but it has gone when I get a prompt.
2. My profile added Program files\windows PowerShell\modules to PSModulePath for PS 6 and 7.
The debugger only works with integrated console. But again, when profile exits (or if I try to change the path during the session) it reverts. So modules which were installed under PS 5 are only loadable when debugging by giving their full path. (I've fixed this by deleting C:\program files\PowerShell\modules and making it a link to WIndowsPowerShell\modules).
I think it still needs looking at ...

[TylerLeonhardt]

Modules installed to ~.vscode\extensions\ms-vscode.powershell-preview-2019.11.0\modules(plaster and PSScript analyzer) aren't loadable.

Please elaborate with why they aren't loadable and what you're seeing. I can't repro this behavior.

---

Unfortunately, we can't do anything about this issue until it's:

• fixed in PowerShell - RunspacePool mutates the PSModulePath PowerShell#9921
  or
• PSScriptAnalyzer is rewritten to not use a pipeline at all

Until then, we are stuck with this behavior.

[jhoneill]

@TylerLeonhardt
OK ... now that's weird. When I created that comment I had this in my profile.

if (($env:PSModulePath -notmatch "C:\\Program Files\\WindowsPowerShell\\Modules") -and
    ($env:PSModulePath    -match "C:\\Program Files\\PowerShell\\Modules") ) { $env:PSModulePath =
     $env:PSModulePath  -replace "C:\\Program Files\\PowerShell\\Modules", "C:\Program Files\PowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules"
}

and with that in , if I do this as the first thing I type in a session...

>$env:PSModulePath
C:\Users\mcp\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;
c:\program files\powershell\6\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

Where did the reference to the extensions folder go ? And now any attempt to change the variable always reverts back.
BUT I recently put in the link to the point program files\PowerShell\modules to program files\WindowsPowerShell\modules so I removed that from my profile while I was typing that comment. And now

>$env:PSModulePath
C:\Users\mcp\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;
c:\program files\powershell\6\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;
c:\Users\mcp\.vscode\extensions\ms-vscode.powershell-preview-2019.11.0\modules

The extension folder is back and I can modify the variable from the prompt.
So.... trying to modify $env:psmodulePath in the profile doesn't merely fail it screws past and future things up. It seems to be something of an edge case :-)