Visual Studio Code is one of the most popular tools. And it is all the more gratifying that it is developing by leaps and bounds. I decided to share my first impressions of remote development in VS Code.
Visual Studio Code Remote Development
Visual Studio Code Remote Development allows you to use a container, remote machine, or the Windows Subsystem for Linux…
Why do we need it?
The remote development capability in Visual Studio Code is the ability to use a container, remote computer, or Windows Subsystem for Linux (WSL) as a complete development environment. In this case, the whole process is divided into two parts: the client part of the application is launched on the local computer, and the VS Code server is almost anywhere. The Remote Development Extension Kit includes three extensions. The following three articles will help you explore each of them in more detail:
- Remote — SSH — gain access to any directory on a remote or virtual machine using SSH.
- Remote — Containers — working with a sandboxed set of tools or containerized applications within a container (or ported into a container).
- Remote — WSL — Application development in the Windows Subsystem for Linux (WSL).
Let me give you a concrete example. Let’s say you need to develop an application in some language, but your computer does not have the language itself, no SDK, or the necessary tools.
Many Windows developers create Windows virtual machines in the cloud, and then connect to the desktop via RDP and run Windows windows. In this case, the virtual machine performs all related operations. Linux developers create Linux virtual machines or containers and connect to them via SSH through the terminal, start vim or tmux and write to the console. In this case, the virtual machine performs all related operations. In both scenarios, it is not a client-server connection that is implemented, but the interaction of the terminal or thin client with the server. VS Code is a thick client with a clear and straightforward language service interface and location transparency.
When you write code — for example, an instance of an object, and after the dot (.) Symbol, you have auto-completion of the names of the contents of this object. Who is doing this job? Where does this list come from? If the code runs locally, and even in a container, you need to make sure that both sides (client and server) are in sync, use the same SDK, and so on. Not an easy task.
Let’s say you don’t have Rust installed on your computer and the tools needed for development.
Then we clone the following repository:
Launching VS Code Insiders:
C:\github> git clone https://github.com/Microsoft/vscode-remote-try-rust
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 .
VS Code then asks if you want to open the given container. The devcontainer.json file contains a list of the extensions required for the current project. The VS Code extensions will be installed into a Docker container and can then be used remotely. Your local system does not need all of them at all, it is enough to install only those that you plan to use in the current project. Of course, you can do without installing anything on your local computer at all, but the golden mean is to get rid of unnecessary manual system configuration.
Take a look at the screenshot below. This is where the tools you need are added to the dockerfile, the Docker executable runs, and we see the VS Code server!
Go to the Extensions section in VS Code and notice the bottom left corner. The green status bar signals that the client-server interaction has been implemented. All the Rust extensions you need are installed in a container and ready to use in VS Code. The entire installation process took a matter of minutes.
By editing the code in this way, you get the same auto-completion, debugging, and more functions.
Here’s an example of a real-time debugging session on a Rust application that requires no configuration other than installing VS Code Insiders, Remote Extensions, and Docker (which I already had).
As I said, you can run code using WSL, in containers, or over SSH . This style of development is only gaining momentum. It is simple and straightforward, and it is very interesting for me to observe where this will lead us. We have to perform so many routine tasks , and remote code editing allows us to throw out all unnecessary from the development process and concentrate our attention on the most important thing.
If you found this article helpful, click the💚 or 👏 button below or share the article on Facebook so your friends can benefit from it too.