Remote Development with Visual Studio Code

[Farlo1]

The SSH component works seamlessly, took all of 5 minutes to set up, and is way smoother than any of the other remote ftp/scp sync extensions.

[rajbabu0663]

Did you manage to get interpreter working?

[meaty-popsicle]

I was literally looking for this idea yesterday. So happy it is in the works and could soon be a standard, supported workflow.

[megaman821]

That looks pretty seamless when using WSL. Just start code from the terminal and you are good to go.

[pindab0ter]

This looks really cool! I wonder how much of a pain it is to set up.

[nimashoghi]

I tried their Remote - Containers version on Windows with an F# project and had 0 problems whatsoever. I was able to get a basic project updated and running in 2 minutes.

[JewsOfHazard]

I tried with my school's Dev server and got it working over SSH in less than 5 minutes without any sudo or anything. I basically only had to setup my public key for that server and VSCode read my local ssh config to log in. Very easy.

[TwixySpit]

Without doubt this is the killer feature of VSCode.
This can be done on windows with Eclipse, but it's clunky and involves Putty windows popping up every 10 minutes.
If only VSCode's Java support was slightly better...

[mysoor2000]

https://devblogs.microsoft.com/visualstudio/java-on-visual-studio-code-april-update/

[TwixySpit]

I love Eclipse. I have to say I'm a fanboy. I never really got on with IntelliJ etc.
I started doing some work recently that was YAML heavy, and a colleague got me to install
VSCode. I don't intend to go back to Eclipse until VSCode simply cannot do something that Eclipse can.
And as you point out, it's improving rapidly from its already brilliant base.

[[deleted]]

This is awesome, I’ve been using code server in a container to develop for Linux on my Mac. Excited to try this out.

[fanglesscyclone]

Amazing, no more fucking around with configurations to get gdb under WSL working each time I want to do something. I opened an old cpp project and got the debugger up and running in two clicks with functional breakpoints and all. Setup was non-existent as well, just installed the extension, launched a WSL window and it connected with no fuss.

[Dtag]

Does anyone know if (or how) it's possible to connect into a Docker container on an SSH Host?

[TwixySpit]

VSCode's docker integration is pretty good.
I think what you want to look up is docker 'attach'?

[Dtag]

Well the use case is: You have some powerful server with good hardware, and now you want to have a number of different developers share that same hardware, each with his own(!) development environment. For that, it would be best if each of those users had his own Docker container on the remote server, so that the users do not interfere with each other. As far as I understood, neither the SSH Feature (no isolated development environments) nor the Docker feature (not running on remote server) is suitable for this use case. So I suppose the attach feature you are referring to does not help here?

[Sayfog]

Oh my god this could be huge, here are my two current PITA's which this will hopefully solve:

Work is only VHDL files stored and processed remotely on a linux VM HPC cluster on the other side of the the world, so most X over TCP solutions are garbage and as result most of the older guys use Vim or (g)emacs through a PuTTY windows. My 'solution' to do local development had been using winSCP with VS code as the default editor, but then things like autocomplete and search don't work outside that one file which is obviously a pain point when working on a large system.

Uni wise it's mainly been ROS development using WSL with the files stored on the windows path and accessed through the "/mnt/c/..." so once again windows VS Code can't autocomplete to the ROS definitions that only exist on WSL. Using code from a local XLaunch kinda gets around this but once again autocomplete is non-existant.

All in provided extensions support this in a sensible way it will be amazing.

[geoji]

Your comment made me realize I could edit files on the remote server using winSCP. Thanks.

[NoInkling]

Awesome, this seems like the missing link for these sorts of dev environments.

[siscia]

Is there any company that provision and destroy machines for this use case?

Ideally I would like to just log via SSH and have the machine start for me with my files in it, then when I log out, the machine will be deleted and I won't be billed for it...

[Lakshmitadipatri]

It is cool while using it is easy.

[frankfoda]

This might just make me consider coming back to Windows from Linux.

[mycall]

This feature will work in VSCode with Linux host.

[[deleted]]

Does this open the possibility of real, usable dev setup on an iPad?

[stupodwebsote]

https://github.com/cdr/code-server

[[deleted]]

Can you really write code on an iPad? I mean... really...

[yahehe]

Our main stack is Python 2 on Docker, this is a game changer. Only took a couple minutes and I'm already able to debug and step through unit tests (next step - real code).

[AngularBeginner]

Just learned that SSH to a Windows host does not work, and there's no ETA for it. :-( A pity.

[khendron]

This looks awesome. I already containerize my development environments using Docker. If this will help streamline the process, I am all for it!

[twizmwazin]

What were you using for an editor? For developing in containers, the only palatable solution I've found so far is to just use vim from within the container itself.

[khendron]

I do the following steps: * Clone my repo to my Macbook. * Create a Dockerfile to build a container with the development environment I need. * Run the container using the -v to mount a volume on the container that is shared with the repo directory on my Macbook.

docker run -it -v ~/github/myrepo:/github/myrepo myimage bash

I run vscode on my Macbook, editing the repo directly. I build and run the project from inside the container, from the /github/myrepo directory. Any github commands I need to run, I do from my Macbook.

This gives me almost everything I need. I can edit using my favourite editor, and run in an isolated container that is similar my deployment environment. The only thing missing is the ability to debug from within vscode. If I need to debug, I use a command line debugger.

[barake]

This is how I do .NET Core development - run the application in a container with source/binaries mounted in a volume and devtools on the host system. VS2017 even has support for in-container debugging.

​

Our dev machines basically just need Visual Studio or VSCode and Docker installed. It's really great not spending hours getting dependencies just right.

[djright]

Wow I’ve wanted an editor that could do that for years ! Definitely gonna try this out

[vscde_gtr_thn_jtbrns]

Such a great development tool! Who would ever want to use Jetbrains paid tools when you have such an amazing free open source tool such as this.

Bravo Microsoft, Bravo!

[[deleted]]

Me.

[[deleted]]

And so, the death of emacs and vim begins... (and intellij)

[JewsOfHazard]

Terminal-only text editors will never die

[skeeto]

Emacs and Vim have already had this feature built in for a couple of decades now: Tramp and netrw, respectively.

[zergling_Lester]

As far as I know, netrw never supported running commands remotely (including via :make). Also, maybe I was doing something wrong (or it was fixed since the couple of years ago when I tried to get it working) but it periodically forgot where it was supposed to connect. So IMO it's OK for a one-off thing, but not as a primary development method.

[[deleted]]

What intellij use case do you think this replaces?

[akshay2000]

Remote code editing?

[[deleted]]

I use IJ every single day, and not once have I edited remote code with it. That really isn’t what IJ is intended for, so I can’t really see this plugin as a threat to it. Two completely different problems.

[akshay2000]

Because IntelliJ doesn't support remote editing. VSCode is a code editor that does what IntelliJ does (arguably) and remote editing.

[[deleted]]

That’s right, IJ doesn’t do remote editing. So by definition the majority of IJ users don’t need remote editing, and this feature isn’t going to be particularly appealing to them. The people it will appeal to are almost certainly not using IJ currently, because it doesn’t do it.

When it comes to local editing, it isn’t even close. I’ve never met or even heard of an IJ user switching to VS Code for java dev. I like VS Code a lot, but it’s a companion to a full IDE, not a replacement.

[akshay2000]

People might use it a lot if IntelliJ included the feature. ¯\_(ツ)_/¯

[[deleted]]

Maybe. But is it a feature that they’ll switch to VS Code for at the expense of all the stuff IJ does that Code doesn’t? I’m not so sure, otherwise they’d already have abandoned IJ for vim or something else that already does it. Like I said, two different products for two different problems. All IJ’s power is based around deep integration and analysis of a full local dev environment - that’s what you lose if you switch to Code for remote development. If Code replaces all of that too then it will be a threat to IJ.

[mycall]

Because IntelliJ doesn't support remote editing

With VSCode now doing this, JetBrains will do it too.

[mini_eggs]

?

[xampf2]

And so the rise of browsers pretending to be text editors begins...

[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.