Scott Hanselman

Visual Studio Code Remote Development may change everything

May 21, 2019 Comment on this post [18] Posted in Docker | Open Source
Sponsored By

DevContainer using RustOK, that's a little clickbaity but it's surely impressed the heck out of me. You can read more about VS Code Remote Development (at the time of this writing, available in the VS Code Insiders builds) but here's a little on my first experience with it.

The Remote Development extensions require Visual Studio Code Insiders.

Visual Studio Code Remote Development allows you to use a container, remote machine, or the Windows Subsystem for Linux (WSL) as a full-featured development environment. It effectively splits VS Code in half and runs the client part on your machine and the "VS Code Server" basically anywhere else. The Remote Development extension pack includes three extensions. See the following articles to get started with each of them:

  • Remote - SSH - Connect to any location by opening folders on a remote machine/VM using SSH.
  • Remote - Containers - Work with a sandboxed toolchain or container-based application inside (or mounted into) a container.
  • Remote - WSL - Get a Linux-powered development experience in the Windows Subsystem for Linux.

Lemme give a concrete example. Let's say I want to do some work in any of these languages, except I don't have ANY of these languages/SDKS/tools on my machine.

Aside: You might, at this point, have already decided that I'm overreacting and this post is nonsense. Here's the thing though when it comes to remote development. Hang in there.

On the Windows side, lots of folks creating Windows VMs in someone's cloud and then they RDP (Remote Desktop) into that machine and push pixels around, letting the VM do all the work while you remote the screen. On the Linux side, lots of folks create Linux VMs or containers and then SSH into them with their favorite terminal, run vim and tmux or whatever, and then they push text around, letting the VM do all the work while you remote the screen. In both these scenarios you're not really client/server, you're terminal/server or thin client/server. VS Code is a thick client with clean, clear interfaces to language services that have location transparency.

I type some code, maybe an object instance, then intellisense is invoked with a press of "." - who does that work? Where does that list come from? If you're running code locally AND in the container, then you need to make sure both sides are in sync, same SDKs, etc. It's challenging.

OK, I don't have the Rust language or toolkit on my machine.

I'll clone this repository:

git clone

Then I'll run Code, the Insiders version:

C:\github> git clone   
Cloning into 'vscode-remote-try-rust'...
Unpacking objects: 100% (38/38), done.
C:\github> cd .\vscode-remote-try-rust\
C:\github\vscode-remote-try-rust [main =]> code-insiders .

Then VS Code says, hey, this is a Dev Container, want me to open it?

There's a devcontainer.json file that has a list of extensions that the project needs. And it will install those VS Extensions inside a Development Docker Container and then access them remotely. This isn't a list of extensions that your LOCAL system needs - you don't want to sully your system with 100 extensions. You want to have just those extensions that you need for the project you're working on. Compartmentalization. You could do development and never install anything on your local machine, but you're finding a sweet spot that doesn't involved pushing text or pixels around.

Reopen in Container

Now look at this screenshot and absorb. It's setting up a dockerfile, sure, with the development tools you want to use and then it runs docker exec and brings in the VS Code Server!

Setting up Rust

Check out the Extensions section of VS Code, and check out the lower left corner. That green status bar shows that we're in a client/server situation. The extensions specific to Rust are installed in the Dev Container and we are using them from VS Code.


When I'm typing and working on my code in this way (by the way it took just minutes to get started) I've got a full experience with Intellisense, Debugging, etc.

Intellisense from a container running Rust and VS Code Remote Containers

Here I am doing a live debug session of a Rust app with zero setup other than VS Code Insiders, the Remote Extensions, and Docker (which I already had).

Debugging in VS Code a Rust app within a DevContainer

As I mentioned, you can run within WSL, Containers, or over SSH. It's early days but it's extraordinarily clean. I'm really looking forward to seeing how far and effortless this style of development can go. There's so much less yak shaving! It effectively removes the whole setup part of your coding experience and you get right to it.

Sponsor: Manage GitHub Pull Requests right from the IDE with the latest JetBrains Rider. An integrated performance profiler on Windows comes to the rescue as well.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
May 23, 2019 2:35
Now I think, VSCode client part can become apps on Android, iOS or UWP. Ubiquitous Dev experience everywhere!
May 23, 2019 4:27
Great, I have to try this with JuliaLang
May 23, 2019 4:45
I have been using this since it released, and its awesome.
May 23, 2019 5:21
The biggest immediate benefit of this could be for millions of Raspberry PI users. The ability to remotely use VS Code for editing and be able to debug with the local GPIO is huge. Unfortunately as of now Raspberry Pi platform is not officially supported. There are attempts by other developers to port from the source code but these do not yet work with the latest insider version that supports remote debugging. Let's home with this new significant feature and it's benefits for IOT, that Raspberry Pi would be part of the official build.
May 23, 2019 6:25
I was super excited when I saw this announcement! Thanks for fleshing it out a bit for us. Hoping this makes its way into stable **really** soon!

BTW, you going to finish that book on relationships? I'd love to read it!
May 23, 2019 9:01
This is remarkable, and the general concept is one of the things I like so much about the Server-Side Blazor model, too. Pushing pixels: thin client. Processing stuff: wherever it makes sense, given acceptable latency for the task (and use tech like SignalR and gRPC to make efficient).

Between a mobile "portal" in our pocket for the low-latency compute, and with serverless compute resources for the rest, imagine how thin and seemless our screens could become.
May 23, 2019 10:43
Wow.. Didn't really get it until about the 3rd read! The fact the extensions are just there from anywhere! My, how we have come along! We do seems to be (again) slowly going back to the age of mini/mainframes but in a cool way ;)

Many thanks! Love the way you cleanly explain these things!
May 23, 2019 15:26
Been using this since the announcement and it is making my workflow so much better. Most of my development is on Linux but for various reasons my PC's main OS is Windows. I always had to resort to some form of remote desktop connection to Linux if I wanted to use VS Code. Now I get all the nice resolution and font clarity of my local box, using the remote SSH plugin developing on project in my Linux host!

For those of you scared of running the Insiders build of VS Code, don't be I've yet to run into any blocking issues. The only thing slightly annoying is it gets updated pretty much daily, but the upgrade is quick and effortless at least. You can also run the Insiders build side by side with the main build without any issues.
May 23, 2019 18:11
I think a very glaring limitation coming from Microsoft is that do not support ssh for windows server. You have to have a Linux-bases ssh server :(
May 23, 2019 19:22
I think for a lot of things, this is probably overkill. But there are many forms of development for which I would love to have this though. In particular I have found that the setup for using python machine learning projects can be grueling. TensorFlow projects usually aren't that bad, but the scientific community is often slow to use new tools. There are many frameworks out there that are older, and more unwieldy that come with a greater number of dependencies and complicated installation steps. Another major issue in that space is trying to manage multiple incompatible versions of the same software and all of the environment variables that go with each tool. For bloated dependencies like that, having a container setup ahead of time would be invaluable to productivity, especially for a team working on the same project.
May 24, 2019 22:10
Amazing tool indeed. Just used it on MacOS Mojave to run my Tesseract project and do some editing there. Amazing tool indeed! All my Intellisense for header and source files are spot on and fast. This will be a perfect tool for Micro-service architecture.
Contain your published app and your dev environment.
May 25, 2019 13:21
It's awesome! demoing it around europe as we speak. Note that RTVS (R tools for visual studio) had this model w R, debug engine, isense, etc. running remotely and VS locally a few years back.
May 25, 2019 17:17

In fact, Visual Studio Online was shown at Build to allow for editing against a remote from anywhere. You can sign up for the private preview of it here: and read more here:

(Full transparency: I’m a PM on the Visual Studio Online team)
May 28, 2019 6:28
It's a pity there's no support for SSH hosts on anything other than Linux yet. I do a bit of react-native development on a mac and would love to be able to set up a server on a mac and use VSCode from Windows.
May 29, 2019 6:41
I also didn't get it until the third read, and then realized it is the solution to accessing Salesforce developer tools on my restricted laptop. I wrote a quick article here about how I did this , building off your article. Thanks!
May 29, 2019 9:31
While cool and, yes, I get the idea and see that this could be great in some situations, there's a nagging sensation somewhere in my brain going on about this being a patchwork solution to a problem that shouldn't even exist, or at least should be looked at properly instead of just patching up. See, this bit here: "you don't want to sully your system with 100 extensions." - I sure as heck don't, but why do I even have to? It's become so commonplace now to build apps from fairly small and specialized blocks that using any one of them will pull many more as dependencies. Want to build anything more substantial? Indeed you will be required to pile up those extensions.

The problem IMO is the number of extensions, and while this is a clever hack on top of that pile, I would much rather see far, far less extensions and frameworks and tookits and transpilers and preprocessors and whatnot. Just for laughs: I recently opened an old WinForms app, a simplistic 2D game, for porting to a more modern framework. The old one, I just pointed visual studio to the repo, cloned it, built and ran - no extensions, no 3rd party libraries, no nothing. That felt good; clean, simple, efficient.

Maybe it's just me (well probably, hehe), but I think there's a level of complexity in development today that isn't exactly optimal for productivity...
May 31, 2019 20:42
Es sind maximal 35 von 37 Trophäen erspielbar.
June 01, 2019 0:17
Any plans to support this in Visual Studio? I would love to develop in .NET Core against container with the full power of Visual Studio...

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.