PowerToys: [PowerToys Run] Visual Studio Code previously opened workspaces not found
Microsoft PowerToys version
0.45.0
Running as admin
- Yes
Area(s) with issue?
PowerToys Run
Steps to reproduce
If you have the “portable” edition (the one mentioned as .zip here, using the Portable Mode) of Visual Studio Code, PowerToys Run is not able to find your workspaces, not even if you use the action key {.
✔️ Expected Behavior
It should detect the automatically or there should be a way to specify where they are if you have a “portable” installation (and therefore they are not in the default folder).
❌ Actual Behavior
PowerToys Run is not able to find any workspace.
Other Software
The “portable” edition (the one mentioned as .zip here) of Visual Studio Code.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 3
- Comments: 22 (5 by maintainers)
Commits related to this issue
- Make launcher detect portable installations of VS Code in system PATH This should fix #13362 — committed to harvastum/PowerToys by harvastum 2 years ago
Adding a setting to specify the location of a portable version would be a way to solve this, indeed.
yes its working perfectly. Thank you
Thought this was finished. I’ll add a Needs Help here. Thank you!
Sorry, there is only so much I can do with blind edits - I do not have an environment to build and test Powertoys and I do not fancy installing VS just for that as I do not write in C#. Hopefully someone more competent will notice this and help. I can confirm it does not work for me either though. @jaimecbernardo can we get a “needs attention” label here?
I completely agree that this would be the best way, especially because this also covers the case where you do not want/cannot have VSCode in the PATH. But this requires a more complex development task (UI elements, settings management, etc.), and requires someone able to do that. While the solution I suggested above, it is extremely quick to implement (you only have to change a few characters in a single line) and could be a (temporary) workaround that will work in most cases (actually, in all cases where you have VSCode in the PATH). And it is not less elegant than the current one since also the current one has an hard-coded value. Unfortunately, I am not able to change that, but I hope someone will do it soon (in one way or another).
I found the culprit. This line grabs all entries from PATH, that contain “VS Code”.
In my case, adding ones that also include “vscode” would solve the issue (this is obviously not universal, but probably somewhat common because of how Scoop works).
On the side note, a similar problem exists with Windows Terminal.