Seamlessly switch (or better, collab) between Local and Remote/WSL

[ParadoxV5]

Currently, Local and Remote are essentially two entire modes for VSCode. This creates an intrusive boundary between working locally and remotely.

For example, when I program in C, I sometimes would like to see my build and run results in Windows as well as on WSL Linux. (I have build tools on both sides to avoid cross-compiling.) Since VSCode needs to be in Local mode for Windows tools while in Remote mode for WSL Linux, I must practically reboot the entire workspace window just to switch between the two toolchains. Compare this with CLion, where after switching, all it does is a quick refresh.

Moreover, I downloaded a Java Development Kit on Windows, but built my Ruby setup on WSL Linux. Unless I re-download the Java DevKit on WSL Linux as well, it is impossible for me to simultaneously work on both Java and Ruby in the same VSCode workspace. The Ruby extensions rely on beïng inside WSL Linux, but Remote mode VSCode refuses to run the Java extensions locally even if I uninstall them on the remote server.

VSCode could do more work to close the gap between local and remote development. I’m open to criticism though if it takes more than an identifier flag to differentiante file/folders between Local and different Remotes.

By the way, when choosing which path to open, there’s a “Show Local” button for opening a local path instead, which opens a separate window in Local mode (even for WSL where the local file system is still accessible via automatic mounts).

[aeschli]

This is related to the architecture we chose for remote development. In a remote window the backend including extensions, terminals, file system, debugger runs in the remote OS. Running multiple backends on multiple OSs would bring many challenges, such as having potentially the same extension loaded multiple times and conflicting functionality. We have no plans to go in that direction.
However WSL has some integrations such as accessing the Windows file system and running Windows commands out of WSL, taht should help with running the build tools accross platforms.
To run language extensions both on Windows and WSL, you'll have to work with multiple windows...

[aeschli]

We have no plans to work on this.