| Applicable to: | PowerShell Core global tool 6.2.2 and 6.2.3. |
| TL;DR; | For the purposes of defining scope, I’m limiting the following analysis to SDKs for .NET Core versions currently in LTS and versions in between. As of this writing, that would be 2.1. 2.2, 3.0 and 3.1. This should work well enough for most cases: – If you can root or sudo, install whatever version of PowerShell you deem appropriate with an installer or package manager depending on your operating system; – Else, if you have .NET Core SDK 3.1, update to PowerShell Core tool 7.0.0; – Else update to PowerShell Core global tool 6.2.4. For details, read on… |
As written in my the last post, installing PowerShell global tool 7.0 solved the issue of initializing PowerShell extension for Visual Studio Code (ms-vscode.powershell).
But there was one thing intriguing me: While trying to initialize the extension, some writing in red was flashing in Code’s integrated terminal.
After capturing it on video and pausing it at precisely the split second the message appears it is possible to read:
-NoProfile: The term '-NoProfile' is not recognized as the name of a cmdlet, funciton, script, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + -NoProfile -NonInteractive -EncodedCommand SQBtAHAAbwByAHQALQBNAG8AZA... + ~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (-NoProfile:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException
Coincidentally, the parameters seen in the error message match those I had seen previously in the extension’s output log…
… from which I removed timestamps, log level, and truncated the log message for better display below:
Visual Studio Code v1.43.0 64-bit
PowerShell Extension v2020.3.0
Operating System: Linux 64-bit
Language server starting --
PowerShell executable: /home/alfred/.dotnet/tools/pwsh
PowerShell args: -NoProfile -NonInteractive -Encoded...
PowerShell Editor Services args: Import-Module '/home/...
pwsh started.
Waiting for session file
Error occurred retrieving session file
Language server startup failed.
The language service could not be started:
Timed out waiting for session file to appear.
It is unfortunate that the extension’s log doesn’t show the same information that, albeit briefly, is shown in the integrated terminal – showing instead a misleading error due to some “session file”.
If we capture those parameters from the log and use them for running PowerShell directly, we’ll receive the same exact error shown in the integrated terminal.
With this we can discard ms-vscode.powershell as the source for the error and instead focus on pwsh itself.
It’s nice to see in practice the link of the failure in initializing the extension to the parsing of arguments in PowerShell Core global tool, but this doesn’t really add that much to the situation given I already had learned this is a known bug:
Older versions of the PowerShell dotnet global tool have a bug in them where arguments are not processed properly, breaking our startup invocation.
Please update your PowerShell version to 7 to enable this, or install a non-global tool PowerShell installation and configure the PowerShell extension to use it…
Although the statement pointed me in the right direction, it is imprecise and may lead some people, as was my case, to incorrect conclusions such as the only two alternatives being into install PowerShell global tool 7.0.0 or using some means of installation other than as a .NET Core tool.
Given I had very little exposure to PowerShell running on operating systems other than Windows and haven’t played at all with .NET Core tools, I took the opportunity to read through the documentation and do some testing. Here are some of my findings:
If you have root permissions or can sudo, you’re probably better off installing PowerShell using any means other than as a .NET global tool. PowerShell Core global tool can be seen as a shim over the “real thing”™, an extra layer that in versions 6.2.2 and 6.2.3 had it’s option parsing broken.
If you can’t sudo or elevate to root, you’ll have to resort to using .NET Core tools. First checkout what SDK versions are installed and confirm that PowerShell is installed as a .NET Core tool:
$dotnet --list-sdks2.1.804 [/usr/share/dotnet/sdk] 3.1.200 [/usr/share/dotnet/sdk] $dotnet tool list -gPackage Id Version Commands powershell 6.2.3 pwsh
Whichever SDK versions are installed, you can always uninstall a given version, then install another version. For instance:
#dotnet tool uninstall -g powershellTool 'powershell' (version '6.2.3') was successfully uninstalled. #dotnet tool install -g --version 6.2.4 powershellYou can invoke the tool using the following command: pwsh Tool 'powershell' (version '6.2.4') was successfully installed.
But upgrading can be done in a single step using dotnet tool update:
# dotnet tool update -g powershell
Tool 'powershell' was successfully updated from version '6.2.3' to version '7.0.0'.
The command above will work as long the latest version of the .NET Core tool on the package repository is compatible with the latest .NET Core SDK version installed locally.
Otherwise, it is necessary to specify the tool version, which can only be done starting with .NET Core SDK 3.0:
# dotnet tool update -g --version 6.2.4 powershell
Tool 'powershell' was successfully updated from version '6.2.3' to version '6.2.4'.
