Make powershell.powerShellExePath a Worksapce Configuration

[markekraus]

I would like to use different PowerShell versions in different in different workspace folders without having to change my user settings for all workspaces. I would like for when powershell.powerShellExePath is set in the workspace, the version of PowerShell define there would load. This is helpful when working switching back and forth between Windows PowerShell and PowerShell Core Projects.

Currently, this setting appears to be a user profile only setting.

I would also like that when powershell.powerShellExePath is set for a work space, and the version used is change in another open VS Code workspace, that i not be prompted to change.

System Details

• Operating system name and version:
• VS Code version:
• PowerShell extension version:
• Output from $PSVersionTable:

PS C:\Users\MarkLocal\Documents\github\PowerShell> code -v
1.21.1
79b44aa704ce542d8ca4a3cc44cfca566e7720f1
x64
PS C:\Users\MarkLocal\Documents\github\PowerShell> $pseditor.EditorServicesVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
1      6      0      0


PS C:\Git\PowerShell> code --list-extensions --show-versions
bbenoist.vagrant@0.5.0
bradygaster.azuretoolsforvscode@2.0.2
CoenraadS.bracket-pair-colorizer@1.0.26
DavidAnson.vscode-markdownlint@0.14.1
DotJoshJohnson.xml@1.9.2
DougFinke.vscode-PSStackoverflow@0.0.2
eamodio.gitlens@8.1.1
EditorConfig.EditorConfig@0.12.1
formulahendry.code-runner@0.9.3
gerane.Theme-TomorrowNight@0.0.2
johnpapa.azure-functions-tools@0.3.3
ms-azuretools.vscode-azureappservice@0.6.1
ms-azuretools.vscode-azurefunctions@0.7.0
ms-azuretools.vscode-azurestorage@0.2.0
ms-azuretools.vscode-cosmosdb@0.5.0
MS-DevSkim.vscode-devskim@0.2.2
ms-mssql.mssql@1.3.0
ms-python.python@2018.2.1
ms-vscode.azure-account@0.3.3
ms-vscode.azurecli@0.4.1
ms-vscode.cpptools@0.15.0
ms-vscode.csharp@1.14.0
ms-vscode.PowerShell@1.6.0
ms-vscode.vscode-azureextensionpack@0.0.8
ms-vsts.team@1.122.0
msazurermtools.azurerm-vscode-tools@0.4.0
Pendrica.chef@0.6.4
PeterJausovec.vscode-docker@0.0.25
robertohuertasm.vscode-icons@7.22.0
streetsidesoftware.code-spell-checker@1.6.5
twxs.cmake@0.0.17
usqlextpublisher.usql-vscode-ext@0.2.11
VisualStudioOnlineApplicationInsights.application-insights@0.4.2
vsciot-vscode.azure-iot-edge@0.1.3
vsciot-vscode.azure-iot-toolkit@0.6.0
yzhang.markdown-all-in-one@1.1.0

Name                           Value
----                           -----
PSVersion                      6.0.2
PSEdition                      Core
GitCommitId                    v6.0.2
OS                             Microsoft Windows 10.0.16299
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Name                           Value
----                           -----
PSVersion                      5.1.16299.251
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.16299.251
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Issue Description

I am experiencing a problem with...

Attached Logs

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

[TylerLeonhardt]

Thanks for this, Mark! Are you able to add any of the other PowerShell settings to workspace level settings?

[markekraus]

This is the only one I have run into that does not work as a workspace setting. I define quite a few normally with regards to the formatting (Team OTBS! WOOT!) and have never had any issues.

[TylerLeonhardt]

Strange... ok I'll look into this.

[TylerLeonhardt]

ok so the isExecutable setting is the culprit.
https://github.com/PowerShell/vscode-powershell/blob/master/package.json#L400

Apparently with that set, the setting can only be set in user settings:
microsoft/vscode#33439 (comment)

I'm going to do some digging to see why/if there's a workaround.

If you don't mind trying something for me, or I'll get to it sometime this week, delete that line in the package.json found here:
~/.vscode/extensions/ms-vscode.powershell-1.6.0
or for insiders
~/.vscode-insiders/extensions/ms-vscode.powershell-1.6.0

I feel like we shouldn't/can't do that, but I can't seem to find any docs on isExecutable.

[markekraus]

@tylerl0706 I don't have the bandwidth and the moment, unfortunately.

But one thought I had about this:

Lets' say you have "powershell.startAutomatically": true, and I create a malicious repo that had powershell.powerShellExePath in the workspace settings (which get distributed with the git clone) and it is pointed at a malicious binary also included in the repo. When you open the workspace and then open/edit a PowerShell file, the malicious binary would be executed. At least... in theory.

[TylerLeonhardt]

Yeah, it makes perfect sense. But we need some sort of work around that's not painful. 🤔

I'd imagine this is a somewhat common problem for folks in the ruby/python/node.js space that have repos that only work on certain version.

[rkeithhill]

@markekraus That is a valid concern - if we made that setting a workspace setting. BTW I removed that isExecutable field in the package.json a few days ago and the behavior was ... uh weird. :-)

Ideally, we wouldn't take that path "verbatim" but as a token to a specific version (desktop/pscore, 32/64, etc). We already enumerate the installed versions of PS Core. Not sure how we'd handle locally built PS Core in that case though. That is probably where you'd want a specific path.

[TylerLeonhardt]

Thanks for testing that @rkeithhill! I guess we can also ask the VSCode team for guidance here.

[markekraus]

RE automatic execution: I'm just throwing this out there, but, would it be possible to 1) determine if the exe setting is coming from the workspace and 2) not auto launch PS it is is? i'm not familiar at all with the codebase or the possibilities here, so just thinking aloud.

[rkeithhill]

If you don't auto-launch the PS integrated console (start PS auto) then the editor is pretty crippled. Auto-completion only completes identifiers in the file, no F8 exec, no PSSA integration, no symbols, etc.

What we could do is add a powershell.developer setting that allows you to specify the path to the ps exe in a workspace setting. Then when you change the PS with the session menu, it only changes the current exePath user setting. So the next time you start VSCode, if the developer path exists it will start up with that PS. If you start VSCode and open a workspace without this setting, it will use the path stored in the exePath user setting.

[markekraus]

What about this design:

Allow configuring multiple exe paths in the user settings with:

"powershell.powerShellExePathWorkspaceConfigs" : {
  "5.1x64":  "C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
  "6.0.2": "C:\\Program Files\\PowerShell\\6.0.2\\pwsh.exe" 
}

Then a workspace setting to allow you to chose from a predefined user setting:

"powershell.powerShellExePathWorkspaceConfig": "6.0.2"

or

"powershell.powerShellExePathWorkspaceConfig": "5.1x64"

again, I have no clue what is and is not possible here.

[markekraus]

Also, understood on the lack of functionality without auto launch. I didn't mean for it to end there. There have been times in the past where I have turn off the automatic terminal feature. You can still start it ad hoc. I'd envisioned a toaster message with a "This workspace is configured to use to launch the integrated terminal do X, Y, Z" or something.

[rkeithhill]

That wouldn't be very convenient on a team? Requiring everyone to configure a "user" setting to make the workspace setting work seems wrong to me.

What if we just skipped the worksapce setting and added a user-setting that allows you to add PowerShell binaires/names to the session list e.g.

"powershell.powerShellAdditionalExePaths" : {
  "PS Core Dev Debug":  "C:/Users/Keith/GitHub/rkeithhill/PowerShell/debug/pwsh.exe",
  "PS Core Dev Release": "<Path to release exe>" 
}

There's no need to list the "installed" version of PS. Like I said, we already enumerate those.

[markekraus]

But selecting them in the list is no different than what we have to do now. This issue is separate from the other where I'd like the PowerShell builds populated in the selector. This issue is about having workspace/project configurable version of PowerShell such that it loads Windows PowerShell or PowerShell Core as defined in the project/workspace so when working on multiple projects at once or in succession, you don't have to select the correct version and then back again on another project.

The pain point now is that I'll be working on a PowerShell Core project and be interrupted by a fire that needs putting out in a Windows PowerShell Project. I close the PowerShell core project. Then I open the Windows PowerShell project do some F8s and F5's things are really not working... because PowerShell core is running in the terminal instead of Windows PowerShell. So I switch the terminal to Windows PowerShell, put out my fire, close the project, then reopen the PowerShell Core project. Now my F8's and F5s are broken because Windows PowerShell is running in the integrated console and not PowerShell Core.

That's why I'd like the PowerShell version to use in the terminal to live with the workspace settings and not the user settings. special exe's don't even play a part in this particular issue. I just brought up a possible abuse vector as an example.

Even if the common paths are pre-defined by the VS Code Extension and the workspace setting can only choose those predefined paths, that would work... so long as that when I open a PowerShell Core project, Core is running in the integrated console and when I open a Windows PowerShell project, Windows PowerShell is running in the console and all of this without me having to switch around all the time... I don't really care what the implementation is 😄

[rkeithhill]

You're right. I was conflating the two issues. Yes, this should be doable. I'd think that we'd add a "powershell.startupPowerShellVersion": user/workspace setting which would probably be a string where you specify the name you see in the session menu e.g.:

"powershell.startupPowerShellVersion": "PowerShell Core 6.0.2",

The extension would still use powershellExePath to store the "current session" setting but on startup it would always look for and use startupPowerShellVersion - if set.