Vscode-powershell: [PSScriptAnalyzer] Locally Installed Module Takes Precedence over Extension-Bundled one

[JustinGrote]

ATTN: @bergmeister @TylerLeonhardt
Moved from: https://github.com/PowerShell/vscode-powershell/issues/2696#issuecomment-628224461
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