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