Removals from $ENV:PSModulePath are not respected.

System Details Output

### VSCode version: 1.36.1 2213894ea0415ee8c85c5eea0d0ff81ecc191529 x64

### VSCode extensions:
aaron-bond.better-comments@2.0.5
CoenraadS.bracket-pair-colorizer@1.0.61
connieth.bubblegum@1.0.1
ed-elliott.azure-arm-template-helper@0.0.17
GrapeCity.gc-excelviewer@2.1.32
j0hnm4r5.laser-theme@0.12.3
mechatroner.rainbow-csv@1.2.0
mermade.openapi-lint@1.0.3
ms-azure-devops.azure-pipelines@1.155.0
ms-azuretools.vscode-docker@0.7.0
ms-python.python@2019.8.29288
ms-vscode.csharp@1.21.0
ms-vscode.powershell@2019.5.0
ms-vscode.powershell-preview@2019.5.0
ms-vscode.sublime-keybindings@4.0.3
philosowaffle.openapi-designer@0.3.0
PKief.material-icon-theme@3.8.1
redhat.vscode-yaml@0.4.1
samcogan.arm-snippets@1.4.17
Sitrusy.90s-anime@1.0.0
sysninja.vscode-ansible-mod@0.0.3
Tyriar.shell-launcher@0.3.0


### 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

[KirkMunro]

Related: PowerShell PR #10257

[rjmholt]

This is due to https://github.com/PowerShell/PowerShell/issues/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 https://github.com/PowerShell/PowerShell/pull/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.