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.
An integrated performance profiler on Windows comes to the rescue as well. Sponsor: Manage GitHub Pull Requests right from the IDE with the latest JetBrains Rider. There's so much less yak shaving! It effectively removes the whole setup part of your coding experience and you get right to it.
I'm really looking forward to seeing how far and effortless this style of development can go. It's early days but it's extraordinarily clean.
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).Īs I mentioned, you can run within WSL, Containers, or over SSH.
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. The extensions specific to Rust are installed in the Dev Container and we are using them from VS Code. That green status bar shows that we're in a client/server situation. 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!Ĭheck out the Extensions section of VS Code, and check out the lower left corner.
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.
You want to have just those extensions that you need for the project you're working on. This isn't a list of extensions that your LOCAL system needs - you don't want to sully your system with 100 extensions. And it will install those VS Extensions inside a Development Docker Container and then access them remotely. There's a devcontainer.json file that has a list of extensions that the project needs. Then VS Code says, hey, this is a Dev Container, want me to open it? Then I'll run Code, the Insiders version: C:\github> git clone Ĭ:\github\vscode-remote-try-rust > code-insiders. OK, I don't have the Rust language or toolkit on my machine. 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. VS Code is a thick client with clean, clear interfaces to language services that have location transparency.
In both these scenarios you're not really client/server, you're terminal/server or thin client/server. 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. 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. Here's the thing though when it comes to remote development. 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.Īside: You might, at this point, have already decided that I'm overreacting and this post is nonsense. Remote - WSL - Get a Linux-powered development experience in the Windows Subsystem for Linux.Remote - Containers - Work with a sandboxed toolchain or container-based application inside (or mounted into) a container.Remote - SSH - Connect to any location by opening folders on a remote machine/VM using SSH.See the following articles to get started with each of them: The Remote Development extension pack includes three extensions. It effectively splits VS Code in half and runs the client part on your machine and the "VS Code Server" basically anywhere else. 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. The Remote Development extensions require Visual Studio Code Insiders. 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. OK, that's a little clickbaity but it's surely impressed the heck out of me.