Abstract: New era of IDE!

  • Author: SHUHARI’s blog
  • Inside Visual Studio Code remote Development

FundebugReproduced according to the original requirements, copyright belongs to the original author.

In a previous article on the interesting project – Running Visual Studio Code in the Browser, I described the Coder development team’s attempt to bring Visual Studio Code to the browser. It was an interesting project, but it wasn’t long before Microsoft officially launched a remote development extension for VSCode, which was officially at a fan-killing pace. According to Coder’s website, they seem to be focusing their efforts on the enterprise version, which is probably a product born at the wrong time. Today we introduce Microsoft’s own remote development platform based on VSCode.

The working principle of

In principle, the VSCode Remote development extension is equivalent to copying the original VSCode from the developer’s own machine to the Remote Host, running as a service, and the local VSCode as the client, coordinating with each other through a Remote communication protocol. The actual development work is mostly done on the server side. What’s special about this architecture is that the extensions we use on a daily basis are also divided into two camps: those related to interface customization, which includes styles, themes, ICONS, and so on running on the client side; Most of the development-related extensions run on the server side. We will see the corresponding changes in the interface later in the hands-on section.

Currently, VSCode remote development supports the following three main modes:

  • Remote SSH: Connects to the Linux server over SSH.
  • Remote Container: Connects to a Docker Container.
  • Remote WSL: Connects to the installed WSL environment.

This article focuses on the first, sSH-based approach. Container mode is basically the same except for some differences in initial configuration. As for the WSL, the way it’s going, it can be considered no different than running Linux from a virtual machine, so I won’t pay much attention to it. Students who want to use this method can refer to the official documentation.

A prerequisite for

In order to use VSCode Remote SSH, first make sure you understand some of its limitations and prerequisites.

  • Remote SSHOnly Linux is supported as the server and the 64-bit version is required. This is probably because Linux only has full SSH server support, while Windows or MacOS require some extra work. Since most production servers are likely to be Linux, this restriction should not be a problem for most students;
  • For specific types of Linux, there are three officially supported distributions: Debian, RHEL/CentOS, and Ubuntu. Many other Linux versions should also work, but are not guaranteed, and some rarer versions are not supported (mainly due to support issues with base environments such as Glibc). Updating glibc and libstdc++ on RHEL/CentOS 6 (Updating glibc and libstdc++ on RHEL/CentOS 6)
  • Of course, to use Container or WSL, you must have a Docker or WSL base environment on the machine;
  • You should have an SSH command-line client on your local machine. For Windows 10, OpenSSH should already be built in, as long as the patch is not too old.PuttyIt is not currently supported.

Install the extension

After confirming that the prerequisites are met, you should install the remote development extension in your own VSCode.

The name of the Remote Development Extension is Remote Development, which is actually an Extension Pack composed of remote-SSH, remote-containers, remote-WSL and Python extensions. In addition to Python being primarily used for feature support, three other extensions are apparent. The extension is still in preview mode, but is ready to install to VSCode (if not, make sure VSCode is later than 1.35).

Configure SSH Key

To connect to the server over SSH, we can use a username/password or an SSH Key. For everyday use, the SSH Key-based approach is a bit more difficult to configure initially, but it is a no-holds-all.

Generating SSH keys and distributing them to remote machines is a routine operation of server o&M. The detailed process will not be described here. There is also a detailed step guide in the official document, which can be referred to if you need it.

As a footnote, for Windows clients, the generated Key is usually located in the %USERPROFILE%.ssh directory. We will use this directory later in the configuration section.

Connecting to the server

The SSH Key is configured to connect to the server. The most direct method is to use the command panel, select remote-ssh: Connect to Host, and enter the server address in user@host format as prompted.

But having to manually enter the address every time you open the environment is obviously inhumane, so remote development extensions provide a way to save the server configuration. The command is also used on the command panel: remote-ssh: Open Configuration File.

This command further prompts us which configuration file to choose to edit.

You can think of the two files in the figure above as representing machine-level and user-level configurations respectively, and user-level configurations should generally be selected. When we open it, we’ll see that it already provides us with a default template. We add the server record to the format and provide an additional location parameter for the certificate file. For the server address and user name, please enter as you wish:

# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
# Host alias
# HostName hostname
# User user

Host test-server HostName <192.168.207.130> User < User > IdentityFile C:/Users/< User >/.ssh/id_rsaCopy the code

After installing the remote development extension, we will notice a remote icon under the activity bar. Clicking this icon will bring up a remote view that contains the servers we have defined. Right-click on the server and select Connect to Host in Current/New Window to open the connection to the server in either the Current Window or a New Window, allowing you to start working.

Initialization of the first connection to the remote server takes a while, and opening it up again will be much faster. Please wait patiently for the server initialization to complete, if all goes well, you should see VSCode switch to remote development mode.

Remote development mode

When working in remote mode, you’ll notice some differences from local development.

First, green text on the left side of the status bar clearly indicates that you are in remote mode (the color may vary with other themes) :

Second, when you use the “Open file” or “Open Directory” command, you will find that instead of the operating system’s local file dialog box, there is a different interface for selecting the path on the remote server:

In addition, you should be aware of the following extended view changes.

As you can see from the figure, remote development extensions and some interface themes are kept locally in VSCode, while extensions for development are disabled locally. Perhaps for performance reasons, these extensions are not automatically installed on remote servers. To enable these extensions remotely, select the Install on SSH

command for that particular extension in the figure. Extension is enabled on SSH

and disabled locally.

What follows is no different from normal native development. You can open directories, edit files, execute programs, and so on. However, it’s important to note that almost everything is done behind the scenes on the server these days, and if you subconsciously think you’re doing it locally, it can get a little confusing at times, so stick with it for a while.

A side note: if your server is Linux and your client is Windows, and you are opening a Git repository, consider configuring the trigger lf = false in Git to prevent unnecessary changes in the processing of changes between platforms.

Set up the

Recently I recorded a course in Visual Studio Code panorama learning, which has a special introduction to the structure of Settings. VSCode setup is a very flexible, but quite complex hierarchy, and in the context of remote development, there is an additional source of remote setup, so the structure is even more complex.

By default, the local VSCode user configuration is automatically applied to the remote server environment, requiring no additional work on our part. However, the client and server are usually different operating systems, and there are inevitably some differences between them, so it is sometimes necessary to configure the remote environment separately. To do this, VSCode provides a command, Open Remote Settings, specifically for editing Remote configurations. Like any Command, you can call it from the Command Palette.

In addition, remote development registers some of its own unique configuration information. Perhaps the chief of these is remote.ExtensionKind. As we discussed earlier in the principles section of this article, VSCode splits extensions into local and remote run types to support remote development mode. In general, VSCode will automatically determine where the extension should go, but there are some cases where it can be a little tricky, so VSCode allows us to configure it ourselves.

{
    "remote.extensionKind": {
        "ext1": "ui"."ext2": "workspace"}}Copy the code

For each extension, we can set it to UI or workspace, which means enabled locally/on the server, respectively. This way, VSCode handles the extension appropriately when it starts remote mode. If you’re still a little confused, I suggest you refer back to the architecture diagram at the beginning of this article.

Some of the technology inside

When working in remote mode, almost all development related operations are done on a remote server. This also includes terminals. You can try typing some commands on the Terminal, and you can see from the prompt and the result that this is not the Windows Cmd on the client, but a real Linux Terminal. In addition, we can see that VSCode creates a.vscode-server directory in the user directory of the remote server, which is actually a complete VSCode program (the long infix conjecture is used to distinguish between sessions, but has not been verified). All development extensions opened on the server are automatically copied to the corresponding subdirectory.

If you want to get some insight into how Remote mode works, the output panel has a remote-SSH view that can provide you with some information. This output is still fairly limited, but you can see some details about starting the service and invoking the command. In addition, the Log (Remote Server) and Log (Remote Extension Host) of the output view also show some server-related Log records.

Personally, I would love to see some of the details of remote development at the source level, but unfortunately, Microsoft’s official code base currently contains only documentation and problem templates, and does not open the source code for remote development extensions. In fact, a closer look at the details of remote development reveals that remote development is in many ways deeply tied to VSCode’s core architecture, so there is a good chance that this extension will be merged into VSCode’s body code as it becomes more and more functional and will no longer appear as a separate extension. Of course, this is my personal opinion, may as well listen to it.

Issues that need attention

VSCode remote development is still in the preview state, and it also has some big changes to the internal architecture of VSCode, there may still be a lot of bugs, there may be some compatibility issues for third-party extensions. If you have problems in use, you can look for or report remote development Issues, or refer to Troubleshooting in the official documentation for Troubleshooting.

If you’re an extension developer yourself, be aware that some of the past practices can be problematic in remote mode, especially with native NodeJS libraries that directly access native functionality. Microsoft also lists some common scenarios that can cause problems, along with suggested solutions, for reference: Supporting Remote Development.

Personal feelings

According to Microsoft’s official vision and the experience of some developers, VSCode remote development is mainly used for cross-platform development, unified development environment, sandbox simulation and other scenarios. For general personal development, my feeling is that SSH management is still a little slower than local development and loses the sense of fluency, and I personally don’t have strong requirements for the above scenarios, so remote development doesn’t make much sense to me, at least for now. Admittedly, this approach leaves a lot to the imagination, and it’s possible to see more useful gameplay in the future, so it’s a direction to watch.

However, from an architectural standpoint, I do have some concerns about this extension. The main problem is complexity. The main issues I see include:

  • At present, the setting level of VSCode is quite complicated, and we can feel from the official Issue that it is difficult to deal with some problems due to too many branches and difficult to manage, even the Microsoft developers can not give clear answers. Remote development makes this structure even more complex;
  • The local/remote classification of extensions also introduces additional complexity to extension management and is not intuitive;
  • It also places an additional burden on extension developers, as some of the usual usages may not work at all in remote mode and require them to understand trivial technical details. Raising the bar for extension developers can be detrimental to VSCode’s thriving ecosystem.

In the long run, is remote development better as a separate product? Er — ACTUALLY, I don’t know.

About Fundebug

Fundebug focuses on real-time BUG monitoring for JavaScript, wechat applets, wechat games, Alipay applets, React Native, Node.js and Java online applications. Since its official launch on November 11, 2016, Fundebug has handled over 1 billion error events in total, and paid customers include Sunshine Insurance, Walnut Programming, Lychee FM, Zhangmen 1-to-1, Weimai, Qingtuanshe and many other brand enterprises. Welcome to try it for free!