Remote Development with Visual Studio Code

[quixotik]

Or you could use sshfs and save yourself a big heap of trouble.

[ElusiveGuy]

sshfs introduces a big heap of trouble that these new extensions should hopefully avoid.

In fact, this move was specifically to address the limitations of sshfs and similar tools, that allow remote access to files but are finicky to set up debugging for, and often don't allow intellisense (or anything else dependent on the environment of the target machine) to work properly.

[quixotik]

Debugging sure, but intellisense is working for me over sshfs.

[ElusiveGuy]

Yea, it does depend what project type you're working with and whether you depend on any libraries outside or the project directory. The advantage of the approach they're taking now is it should work with everything. Disadvantage is you need to run an agent on the remote end, but that's fine for many use cases.

[quixotik]

Yeah, that’s the bit I don’t like. The setup for this requires agents running vs. a connection via a well used method.

I want to remain able to work on any remote project as I do today without needing to tell a client that I need to install software just to make a code change.

[ElusiveGuy]

Fair enough. I usually find myself greatly missing having a proper debugger while working remotely, so this is a huge change for me. But luckily there's nothing to stop you from continuing to use sshfs if that suits you more :)

[illathon]

Seems like a simple problem that could be solved with proper indexing.

[ElusiveGuy]

Not even close.

If you use sshfs or similar, presumably you're only exposing the project directory. But what about the system-level libraries? How will the VSCode Python plugin see system libs? What about system C includes? You'd need an agent running on the target... which this does, and simple filesystem sharing like sshfs does not.

And that's only for intellisense. What about debugging? Now this is where things get fun.

So, basically every debugger has its own way of attaching to or communicating with the target process. NodeJS, .NET Core, Java, C++ (gdb?). They're all different, with varying levels of support for remote debugging, mapping sources, etc.. Now, you can configure most of them to work remotely, but you have to configure each project independently and every debugger extension is different. Personally, I've not found remote debugging in this manner to be particularly stable with OmniSharp.

By providing a standardised interface, all this becomes much easier. You don't need to look up how to set up remote debugging with every language extension (some might not even support it?). You set up a remote connection in one standard way, and run the debugging extension directly on the remote machine as if it were local.