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.

[markekraus]

That would work for me!!!

[rjmholt]

I was thinking of something similar to @markekraus' suggestion while reading through #1242 as well.

I feel like configuring a dictionary of PowerShell executable paths once on a machine in user settings seems like a lightweight strategy (and we can always work out how to automatically discover them later). And very flexible, since users can pair any key and path they like.

We can start with a default, or maybe a set of defaults, that come from standard paths. And then using the key in the workspace settings makes that malicious binary exploit the same as just setting the user setting (which is already available).

I don't really know how VSCode's configuration files/settings work or are handled, but the user/workspace key/value configuration feels close to the ideal to me, so wouldn't mind trying to make it work.

[rkeithhill]

We can start with a default, or maybe a set of defaults

Those default will get out of date pretty quickly based on PS Core shipping updates every few months. Besides, it doesn't seem right to supply a config for a version of PowerShell that isn't actually installed. And that default changes based on the platform. Last I checked, Windows PowerShell doesn't run on Linux/macOS. :-)

Therefore, the user setting would start out empty as defined in the package.json. When the user moves that into their user settings then they would have to fill in the values. My point, is there would be no need to do that for installed versions of PowerShell we detect on the system. The user can still specify one of the installed versions by name in the workspace setting. OTOH the user setting would allow folks to specify paths to named local builds of PowerShell.

[rjmholt]

If that method involves having two sets of PowerShell paths (those we detected and those users added) which we can't switch between transparently, then I could imagine that being frustrating for users.

The actual config file should probably begin with nothing in it, but the autodetected PowerShell installations in my mind should behave exactly like user configured ones, rather than having two classes of PowerShell.

So I definitely agree with you @rkeithhill that we shouldn't put default paths in or things that will get out of date. By "default" I'm really trying to say that when you run VSCode it should autodetect standard PowerShell installations and just work (as it currently does), and when you add other PowerShell executables in a user configuration, they should appear right alongside the standard PowerShell installation with their label. So that even though one is detected and the other is user-configured, the user experience in switching between them is the same.

[rkeithhill]

I think we are in violent agreement. :-)

[TylerLeonhardt]

So, what about an array of folder paths? Then we can remove isExecutable from the setting.

powershell.powerShellExePath: [ "path/to/folder/with/pwsh",
"path/to/folder2/with/pwsh"
]

Then those get automatically added to the list of PowerShell versions to switch to.

[markekraus]

@tylerl0706 How would you select which one as the default in the workspace?

On reason I suggested a JSON object was so a workspace could have a name setting, but the user could over ride that path in their own settings. For example, a PowerShell Core module project being worked on by a macOS user and a Windows user. The workspace setting would be arbitrary

This would be on the workpace and ships with the SCM repository:

"powershell.powerShellExePathWorkspaceConfig": "MyModule"

The windows dev would have this in their user settings:

"powershell.powerShellExePathWorkspaceConfigs" : {
  "MyModule": "C:\\Program Files\\PowerShell\\6.0.2\\pwsh.exe" 
}

and the macOS Dev would have this in their user settings:

"powershell.powerShellExePathWorkspaceConfigs" : {
  "MyModule": "/usr/local/bin/pwsh" 
}

or something...

[rjmholt]

Yeah, to add to @markekraus, I was imagining something like:

User settings:

{
    "powershell.powerShellExePathWorkspaceConfigs": {
        "5.1": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
        "6.0.2": "C:\\Program Files\\PowerShell\\6.0.2\\pwsh.exe",
        "dev-master": "C:\\Users\\me\\Dev\\PowerShell\\src\\powershell-win-core\\Debug\\netcoreapp2.0\\win7-x64\\publish\\pwsh.exe"
    }
}

And then in the workspace settings:

{
    "powershell.powerShellExe": "dev-master"
}

[rkeithhill]

Ditto @markekraus / @rjmholt however I was suggesting we call it:

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

I'm not keen on the name powerShellExePathWorkspaceConfigs because you don't need a workspace setting/config for this to be useful.

Then in your workspace's settings.json file you could set another property called:

"powershell.startupPowerShellVersion": "PS Core Dev Debug",

or perhaps

"powershell.defaultPowerShellVersion": "PS Core Dev Debug",

The existing powershell.powershellExePath would stay as it is - tracking the currently (and last) selected version of PowerShell but a workspace setting could override that version.

[rjmholt]

@rkeithhill, yes I'm very much in favour of those suggestions.

Also, I assume we're locked in to the inconsistent camel-casing of "power[sS]hell"?

[rkeithhill]

If you are referring to the setting prefix, then yes but I think that is the "VSCode way". For instance, all the TypeScript settings start "typescript":. All the language names are lower-case for the settings.

[markekraus]

@rkeithhill I'm cool with whatever name. I am bad at naming things so long as the design is flexible and make sense I'm cool with whatever :)