Locally installed PSScriptAnalyzer module takes precedence over bundled one

[JustinGrote]

ATTN: @bergmeister @TylerLeonhardt
Moved from: #2696 (comment)
Issue also reproduced by @PrzemyslawKlys

Issue Description

If you have an older version of PSScriptAnalyzer (1.18.* in my case) in your modules folder and have not updated to the latest, this is taking precedence and the assemblies for this are loading in the integrated terminal, rather than the "bundled" vscode one. This prevented for instance parameter casing "format document" from working correctly until I deleted my "modules" version of PSSA and reloading, then it worked fine.

This is on a "fresh" load:

Potential Remediations

1. Adjust loading process to prioritize either "latest version regardless" or "bundled extension"
2. Use AssemblyLoadContext to load PSScriptAnalyzer to not expose it to integrated terminal

Attached Logs

Follow the instructions in the README about
capturing and sending logs.

Environment Information

Visual Studio Code

Name	Version
Operating System	Windows_NT x64 10.0.19041
VSCode	1.46.0-insider
PowerShell Extension Version	2020.5.0

PowerShell Information

Name	Value
PSVersion	5.1.19041.1
PSEdition	Desktop
PSCompatibleVersions	1.0 2.0 3.0 4.0 5.0 5.1.19041.1
BuildVersion	10.0.19041.1
CLRVersion	4.0.30319.42000
WSManStackVersion	3.0
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1

Visual Studio Code Extensions

Visual Studio Code Extensions(Click to Expand)

Extension	Author	Version
azure-account	ms-vscode	0.8.11
azure-pipelines	ms-azure-devops	1.165.1
better-align	wwm	1.1.6
better-powershell-syntax-highlighting	justin-grote	0.0.2
bracket-pair-colorizer-2	CoenraadS	0.1.3
gistfs	vsls-contrib	0.0.67
git-graph	mhutchie	1.22.0
gitdoc	vsls-contrib	0.0.6
gitlens	eamodio	10.2.1
indent-rainbow	oderwat	7.4.0
markdown-all-in-one	yzhang	2.8.0
powershell-preview	ms-vscode	2020.5.0
remote-containers	ms-vscode-remote	0.117.1
remote-ssh-edit-nightly	ms-vscode-remote	2020.4.9540
remote-ssh-nightly	ms-vscode-remote	2020.4.9540
remote-wsl	ms-vscode-remote	0.44.2
todo-tree	Gruntfuggly	0.0.174
vscode-icons	vscode-icons-team	10.1.1
vscode-peacock	johnpapa	3.7.2
vscode-pull-request-github	GitHub	0.16.0
vscode-sort-json	richie5um2	1.18.0
vscode-yaml	redhat	0.8.0
vscode-zipexplorer	slevesque	0.3.1
vsonline	ms-vsonline	1.0.2167

[bergmeister]

In my experience, if PSSA is installed AND of higher version, then it will and should take precedence.
But if the version is lower then in your case, then it sounded a bit unexpected at first. However, thinking about it again, module loading is determined by the PSModulePath environment variable. I cannot remember if it goes through all modules and picks the highest one or stops on the first module it finds. If the latter is the case then this is actually by design. Can you clarify @rjmholt @TylerLeonhardt ?

[rjmholt]

It should use the highest version on the module path

[SydneyhSmith]

Thanks @JustinGrote that is unexpected behavior...it would be interesting to also see the output of Get-Module PSScriptAnalyzer -ListAvailable

[PrzemyslawKlys]

If you have 1.19.0 installed as module outside of VSCode it will take precedence.

[TylerLeonhardt]

Can you all run this in the PowerShell Integrated Console:

Get-Runspace | % {
    $_.Name
    try {
        [PowerShell]::Create($_).AddCommand("gmo").Invoke()
    } catch {
      "Failed which is ok"
    }
}

You should get back one of them that has PSSA imported. That will give us the version that's actually being used.

[JustinGrote]

This is on a fresh reload of vscode, only thing that would have run is my profile (and there's no PSSA related loading stuff in there). Tried without profile same result.

Get-Runspace | % {
>>     $_.Name
>>     try {
>>         [PowerShell]::Create($_).AddCommand("gmo").Invoke()
>>     } catch {
>>       "Failed which is ok"
>>     }
>> }

Runspace1
Failed which is ok
Runspace4
Failed which is ok
Runspace6
Failed which is ok
Runspace7
Failed which is ok
Runspace8
Failed which is ok
[appdomain]::CurrentDomain.getassemblies() | where location -match 'script' | % location

C:\Users\jgrote\Documents\WindowsPowerShell\Modules\PSScriptAnalyzer\1.19.0\Newtonsoft.Json.dll
C:\Users\jgrote\Documents\WindowsPowerShell\Modules\PSScriptAnalyzer\1.19.0\Microsoft.Windows.PowerShell.ScriptAnalyzer.dll
C:\Users\jgrote\Documents\WindowsPowerShell\Modules\PSScriptAnalyzer\1.19.0\Microsoft.PowerShell.CrossCompatibility.dll
C:\Users\jgrote\Documents\WindowsPowerShell\Modules\PSScriptAnalyzer\1.19.0\Microsoft.Windows.PowerShell.ScriptAnalyzer.BuiltinRules.dll

[rkeithhill]

Would it be possible to name the runspace we use for PSSA?

[rjmholt]

Would it be possible to name the runspace we use for PSSA?

It depends. There are some places where we use a runspace pool, and PSSA uses its own runspace pool as well

[TylerLeonhardt]

weird it didn't work for you @JustinGrote... maybe it's a Windows/macOS difference...

[rjmholt]

@JustinGrote what's the output of gmo -list PSScriptAnalyzer for you in the integrated console?

[JustinGrote]

gmo -list psscriptanalyzer



    Directory: C:\Users\jgrote\Documents\WindowsPowerShell\Modules


ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     1.18.3     PSScriptAnalyzer                    {Get-ScriptAnalyzerRule, Invoke-ScriptAnalyzer, Invoke...


    Directory: C:\Users\jgrote\.vscode-insiders\extensions\ms-vscode.powershell-preview-2020.5.0\modules


ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------                                          
Script     1.19.0     PSScriptAnalyzer                    {Get-ScriptAnalyzerRule, Invoke-ScriptAnalyzer, Invoke...

[PrzemyslawKlys]

Btw, it's not only related to PSScriptAnalyzer. It's for all modules - right now for Pester

It seems the version is ignored?

[PrzemyslawKlys]

Weirdly enough, the same thing applies to standard Terminal

[SydneyhSmith]

@PrzemyslawKlys thanks for the additional info, unfortunately that's a slightly different issue--the way Import-Module works (if no version parameters are used) is that it imports the first version of the module found on the module path (rather than searching all paths and importing the latest one), in the case of how the PowerShell extension imports PSSA we specifically search for the latest version

[ghost]

This issue was closed automatically as repro info was indicated as needed, but there has been no activity in over a week. Please feel free to reopen with any available information!

[andyleejordan]

Hm, I'm going to re-open this. For PSReadLine we decided to specifically only load the bundled copy of the module, and when we pull in the upcoming PSScriptAnalyzer release (v1.20.0) I would like to change the logic to match. There are too many potential pitfalls when PSES is allowed to just import anything on the system.