Increase support to Remote Development

[alefragnani]

The Remote Development support started with #284 and #318 , with the following idea:

You can

• Open any projects using the Open and Open in New Window commands
• Use the Side Bar, and most of its commands

You can not

• Save projects using the Save Project command

The Save Project command was disabled because if you use it, it could save "remote folders" in your "local projects". So, if you select that "remote folder", it would try to open it locally, because there is not way to know it was "remote"

The full support (whatever it means for each user, myself included) depends on feedback.

Based on these comments #284 (comment), #284 (comment) and #284 (comment), it appears some users where installing the extension remotely (an unpredicted scenario) and were being able to use the Save Project command. I'm not sure the extension should be installed on remote, instead of support to be used on remote, but let's see.

This issue will be use to gather information from users, to combine the remote experiences, and see how the extension would embrace that scenario.

[artbycrunk]

Let me add my scenario here, it might be an edge case, but the extension did work to my expectations before the update.

I work from multiple machines (A. Windows Desktop, B. Linux Headless, C. Macbook)
B holds all of my workspaces and projects data, which I connect to using A or C via remote dev.
Alongside I will develop code on windows using A, and project for macOS using C.
So I use project manager on A, B and C, all having their own projects, while A and C can access projects from B when in remote dev mode.
Apart from this, I access B from any other machine in the world using VPN, in which case I am not interested in the local projects, but the projects that exist on computer B.

Now after the update, when I connect to computer B, I can only access the projects from the local machine.

I'm not able to wrap my head around why one would want to access local projects when in a remote dev session?? cause that would just get you out of the current session and back to doing local development?

That being said, I am sure my workflow will break someone else's normality, hence it might be better to have a setting that allows the user to switch between having the extension save when in remote mode or not.

[gencer]

@alefragnani

Previous version

When using locally, all projects are saved to local AppData folder on Windows.
When remotely connected to Linux Host via SSH, All project manager settings saved and read from remote server.

This way, we can separate both configurations.

• When I use local VSCode, I see locally saved projects not remotes.
• When I use remotely connect to SSH, I only see remotely saved projects. This way i never mix local and remote configuration files.

Basically, each environment has its own extension and its own project setting.

New Version

All messed up. Can't see remote projects anymore. Have to trick settings to remotely see them.
Cant even save but edit manually of course.

• When using local i see local projects
• When i connect to SSH i still see local projects if setting *kind did not set.
• Can't save remote projects to remote server settings.

Solution

• Downgrade
• Fork and create our own version (Not a real solution)
• Revert the commits responsible of this change until we find a proper way of doing it.

[nicolajkirchhof]

I also liked the functionality before the update better. In my case, I've one computer I'm usually working from and multiple remote machines (iot gateways) with different projects. It was a great convenience to be able to install the project manager on these machines and load/store my projects.

[requinix]

Apparently VS Code's remote feature is deliberately designed so that extensions are supposed to be installed separately within WSL - you can see this by opening a new WSL window for the first time, when it will tell you that many of the extensions were disabled. Opening the list of extensions shows you all the ones installed (on the host), and it's easy to reinstall each one within WSL as well.

That's what everybody using Project Manager from within WSL was doing. It fits with the design and worked perfectly well. In fact, the separation of projects on the host and projects in WSL was useful to me. This update removed that separation between host and WSL environment, causing the problems and drawbacks. In my opinion the change should be reverted and instead the host vs. WSL behavior could be briefly documented, eg:

Note that when using the Remote - WSL extension, Project Manager must be installed again within the WSL environment. Additionally, the list of projects stored on the host will be different from the list of projects stored within WSL.

For the people affected:
Downgrading is annoying, so instead do what was mentioned a couple times in #284: add this to your settings.json.

"remote.extensionKind": {
    "alefragnani.project-manager": [
        "workspace"
    ]
}

(It can be a string or array - VS Code autocompleted an array for me so I think that's the preferred syntax.)

[neighthan]

I'm not sure what you mean about Save Project being disabled? I'm on version 10.10.0, and when working in a remote (ssh) folder, I can still save the project. However, I can't load such a project because it tries to open it locally. Am I on an old version? It would be nice to not have it appear that I can save a project when it doesn't really work. My optimal usage would be that I can see all projects (even remote ones) from my local machine and selecting a remote project will establish a remote connection and open it. However, I'd also find it nearly as good if when I'm connected to a remote machine, I only see the projects that I've saved on that machine. Right now, I see all projects on all machines, but the remote ones are unusable. I don't mind installing the extension on each remote host if that's easier to achieve one of these behaviors with.

For now, @requinix's workaround is working for me - it allows you to install Project Manager on the remote machine (close and re-open VS Code after updating your settings if this isn't possible right away) so you can just see the projects on each machine.

[gencer]

@neighthan, new version saves and loads from local wherever extension runs on remote or local. Old version reads from and save to specific remote.

For the workaround: It only enables extension remotely. It does not enable save project feature on remote.

[wiraki]

Agree with most previous comments here, I work on one Windows machine and I remote to other systems where I have projects saved. It was more convenient before, when I could load my remote projects when I remote, and my local projects when I stay on local.

[wongjn]

I have downgraded back to 10.9.1 since that does what I wanted in regards to managing my workspaces which are all on a Linux VM while the machine I am on is Windows.

[vnijs]

@wongjn How did you down-grade? I have 10.9.1 stored (see link below) but every time I try to uninstall and install from vsix I still end up with version 10.10 for some reason

https://github.com/radiant-rstats/docker/blob/master/rsm-msba/vsix/alefragnani.project-manager-10.9.1.vsix

[wongjn]

Kept clicking Install another version > 10.9.1 then Reload required in both remote and local sections in the Extensions sidebar over and over until it stuck.

[vnijs]

That is somehow awesome ... and also not :) Thanks @wongjn

[adawalli]

I recommend following @requinix's solution above instead of downgrading.

[gencer]

@requinix's recommendation is not a solution. It just enables extension remotely. What we need here is to be able to use remote project settings on remotes and locals on locals.

There is no solution except downgrading to 10.9.

[requinix]

If enabling the extension remotely (albeit without the ability to save projects) is not a solution then neither is downgrading to an older version. I can argue semantics all day.

For people who consider saving new projects to be important, and editing the JSON isn't acceptable, then downgrading is the only option. Obviously. But for people like me who don't need new projects or don't mind the 30 seconds with JSON to do it manually, the workaround I posted is quick and easy.

To each their own, yeah?

[gencer]

Fair enough.

[Christilut]

@alefragnani
I asked on the VSCode repo: microsoft/vscode#89952

Maybe that can be of help? I tried using that path syntax, but got the error The path ... does not seem to exist on anymore on disk. Not sure if that is the openFolder function giving an error or something else though.

[alefragnani]

Hi @Christilut ,

Yes, that will help 👍 . Not exactly to work remotely (as it was working prior this update) but for my initial idea of remote support (local installation opening remote workspaces).

Thank you

[vnijs]

Another option is to use codeserver (i.e., VSCode in a browser on remote). I use it with my students from a docker container. Since VSCode (codeserver) is now actually running on a remote, you don't have any issue with project manager

https://github.com/cdr/code-server
https://github.com/radiant-rstats/docker/blob/master/install/rsm-msba-linux.md#using-vs-code-for-python

[alefragnani]

Hi everyone,

Just released v10.11.0, which makes the Save Project command enabled again, even when connected on remotes. The idea is to give you the opportunity to install the extension remotely, like some of the comments above. You still need to add the User Setting commented by @requinix. I hope this could be remove in future releases.

"remote.extensionKind": {
    "alefragnani.project-manager": [
        "workspace"
    ]
}

I would say this is just another step on the journey to make the extension to work on Remotes. As I previously commented here, I have an idea of what I call full support, which is similar to what @neighthan commented here. The VS Code issue commented by @Christilut is a start.

As I said in the related issues, I don't use remotes that much, so the use cases you provide are crucial to define how the extension should and should not work.

Thank you, for your patience, and valuable feedback 👍

[alefragnani]

It appears the latest release has worked as expected, allowing you to use the extension locally and remotely. So, I'm closing this issue to focus on other scenarios and features.

One of the ideas to improve remote experience is to allow you to open remote projects, right from you local machine. That's right, you will be able to save any remote project (WSL, SSH, Docker) as a Favorite project and open it from Project Manager's Side Bar and/or the Project Manager: List Projects to Open... command in the Command Palette , just like you can do with File: Open Recent command.

For those of you interested in this feature, I suggest you to leave comments, suggestions and a 👍 in #345.

Thank you