Exploration of Visual Studio Code Remote Development

Time:2019-8-7

Summary:IDE New Era!

  • Author: SHUHARI’s blog
  • Original: Visual Studio Code Remote Development Exploration

Fundebug is reproduced in accordance with the original requirements and the copyright belongs to the original author.

In the interesting project of previous articles, running Visual Studio Code in browsers, I introduced the attempt of the Coder development team to move Visual Studio Code into browsers. It’s an interesting project, but it’s not surprising that Microsoft officially launched VSCode’s remote development extension soon afterwards, which is the rhythm of the officialdom killing its peers. From the information on Coder’s official website, it seems that they have focused on the enterprise version, which should be considered an untimely product. Today we will introduce Microsoft’s own remote development platform based on VSCode.

Working principle

Exploration of Visual Studio Code Remote Development

In principle, VSCode remote development extension is equivalent to copying the original VSCode on the developer’s own machine to the remote Host and running in the form of service, while the local VSCode is the client. They coordinate and cooperate with each other through the remote communication protocol. In fact, the development work is mainly focused on. It’s done on the server side. What’s special about this architecture is that the extensions we use in our daily life are also divided into two camps: those related to interface customization, mainly including styles, themes, icons and so on, which run on the client side; and most of the extensions related to development run on the server side. Later in the actual operation section, we will see the corresponding changes in the interface.

At present, VSCode remote development supports the following three main modes:

  • Remote SSH: Connect to Linux server through SSH;
  • Remote Container: Connect to the Docker container;
  • Remote WSL: Connect to the installed WSL environment.

This paper mainly introduces the first method based on SSH. In addition to some differences in initialization configuration, container mode is basically the same in specific use. As for WSL, in the current direction of development, you can think of it as no different from running Linux from a virtual machine, so I won’t pay special attention to it. Students who want to use this method can refer to official documents.

Precondition

For useVSCode Remote SSHFirst, make sure you understand some of its limitations and prerequisites.

  • Remote SSHLinux is only supported as a server and must be 64-bit. This may be because Linux has complete SSH server support, and Windows or MacOS requires some extra work. Since most production servers should be Linux, I believe this restriction is not a problem for most students.
  • For the specific types of Linux, the official support includes Debian, RHEL/CentOS and Ubuntu. Many other Linux versions should also work, but there is no guarantee that some of the rarer versions are not supported (mainly because of the support problems of basic environments such as glibc). In addition, CentOS is better than 7.x, and 6.x version usually needs some adjustment to work (see: Updating glibc and libstdc + + on RHEL / CentOS 6);
  • Of course, to use Container or WSL, there must be a Docker or WSL infrastructure on the machine;
  • There should be SSH command line clients on the local machine. For Win10, as long as the patch is not too old, OpenSSH should be built in.PuttyAt present, it is not supported.

Installation Extension

Verify that the prerequisites are met, and then install remote development extensions in your VSCode.

Exploration of Visual Studio Code Remote Development

The name of the remote development extension isRemote DevelopmentIt is actually an Extension Pack, which is composed ofRemote-SSHRemote-ContainersRemote-WSLas well asPythonFour extensions are combined, exceptPythonIn addition to functional support, the other three extensions are obvious. The extension is still in the preview state, but it can be installed into the official version of VSCode (if not, make sure that the version of VSCode is higher than that of VSCode).1.35)。

Configure SSH Key

To connect to the server via SSH, we can use username/password or SSH Key. For everyday environments, the SSH Key approach is once and for all, although the initial configuration is a little more cumbersome.

Generating SSH Key and distributing it to remote machine is the normal operation of server operation and maintenance, and the specific process will not be repeated. Official documents also have a more detailed step guide, which can be referred to by students who need it.

In addition, for Windows clients, the generated Key is usually located in the% USERPROFILE%. SSH directory. We will use this directory in the subsequent configuration section.

Connect to the server

With SSH Key configured, you can connect to the server. The most direct way is to select commands through the command panelRemote-SSH: Connect to HostThen enter the format as prompted[email protected]Server address.

Exploration of Visual Studio Code Remote Development

However, it is obviously inhumane to enter the address manually every time the environment is opened, so the remote development extension provides us with a way to save the server configuration. This method is also typically invoked through the command panel:Remote-SSH: Open Configuration File

Exploration of Visual Studio Code Remote Development

This command will further prompt us to select which configuration file to edit.

Exploration of Visual Studio Code Remote Development

You can assume that the two files in the figure above represent machine-level and user-level configurations respectively. Usually, user-level configurations should be selected. When you open it, you will see that it has provided us with a default template. We add server records in format and provide an additional location parameter for the certificate file. For the server address and username, please enter it according to your actual situation:

# 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_rsa

After installing the remote development extension, we will notice that there is an additional remote icon under the activity bar. Clicking on the icon will bring up the remote view, which contains the servers we have defined. Right-click on the server and selectConnect to Host in Current/New WindowIt opens a connection to the server in the current window or in a new window, allowing you to start working.

Exploration of Visual Studio Code Remote Development

Initialization takes a while to connect to the remote server for the first time, and it will be much faster to open it again later. Please wait patiently for the server initialization to complete. If everything works, you will see that VSCode has been transformed into remote development mode.

Remote Development Model

When the working environment is in remote mode, you will notice some differences from local development.

First, the left side of the status bar clearly indicates that the current remote mode is in green text (the color may vary with other topics):

Exploration of Visual Studio Code Remote Development

Secondly, when you use the “Open Files” or “Open Directories” command, you will also find that the display is no longer the local file dialog box of the operating system, but a different interface for selecting the path on the remote server:

Exploration of Visual Studio Code Remote Development

In addition, you should pay attention to the following changes in the extended view.

Exploration of Visual Studio Code Remote Development

From the figure, we can see that remote development extensions and some interface topics are retained in the local VSCode, while extensions for development are disabled locally. Perhaps for performance reasons, these extensions are not automatically installed on remote servers. To open these extensions remotely, you need to select specific extensions in the diagram.Install on SSH <server>Order. For extensions that have been installed to the remote end, prompts are displayedExtension is enabled on SSH <server> and disabled locally

The next operation is no different from ordinary local development. You can open directories, edit files, execute programs, and so on. However, it should be noted that almost all operations are done on the server behind the scenes. If you subconsciously think that it is local operation, sometimes it will be a little confused, so you should stick to it for a while.

Another additional suggestion: If the server is Linux and the client is Windows, and you are about to open a Git repository, consider configuring it in Git.autocrlf = falseIn order to avoid inexplicable changes caused by different platforms’different handling of newlines.

Set up

Recently, I recorded a course Visual Studio Code Panoramic Learning, which has a special introduction to the structure of the settings. The setting of VSCode is a very flexible but rather complex hierarchy. In the context of remote development, there is an additional source of remote settings, so the structure is more complex.

Exploration of Visual Studio Code Remote Development

By default, local VSCode user configurations are automatically applied to remote server environments without additional work. But clients and servers are usually different operating systems, and there are inevitably some differences between them, so sometimes it is necessary to configure the remote environment separately. For this purpose, VSCode provides a commandOpen Remote SettingsSpecialized for editing remote configurations. Like other commands, you can call it from the Command Palette.

In addition, remote development also registers some unique configuration information. Perhaps the most important of these isremote.extensionKind。 As we explained in the previous part of this article, in order to support the remote development model, VSCode divides the extensions into two types: local and remote. Generally speaking, VSCode automatically determines where the extension should be located, but there are some situations that may not be well judged, so VSCode allows us to configure it ourselves.

{
    "remote.extensionKind": {
        "ext1": "ui",
        "ext2": "workspace"
    }
}

For each extension, we can set it touiperhapsworkspaceThat means enabling it locally/on the server. In this way, VSCode will make appropriate processing for the extension when starting remote mode. If you still feel a little confused, I suggest you go back and look at the schematic diagram at the beginning of the article.

Some technology internals

When working in remote mode, almost all development-related operations are performed on remote servers. This also includes terminals. You can try to enter some commands in the terminal, and you can see from the prompts and results that this is not the Windows Cmd of the client, but a real Linux Terminal. In addition, we will find that VSCode will be built in the user directory of the remote server..vscode-serverThe directory is actually a complete VSCode program (that long infix conjecture is used to distinguish different sessions, but it has not been specifically verified). All development extensions opened on the server side are automatically copied to the corresponding subdirectories.

Exploration of Visual Studio Code Remote Development

If you want to know something about remote mode, the output panel has oneRemote-SSHViews can provide you with some information. This output still shows a limited amount of content, but you can also see some details of the startup service and the invocation command. In addition, the output view’sLog (Remote Server)andLog (Remote Extension Host)Server-related log records are also displayed.

Exploration of Visual Studio Code Remote Development

I personally would like to know some details of remote development work from the source level, but unfortunately, there are only some documents and problem templates in Microsoft’s official code base, and there is no open source for remote development extensions. In fact, careful study of some details of remote development can realize that remote development in many ways needs to be deeply bound to the core architecture of VSCode, so it is very possible that this extension will be merged into the main body code of VSCode after the function is gradually stabilized, and will no longer appear as a separate extension. Of course, this is my own family statement, you might as well listen to it.

Questions needing attention

VSCode remote development is still in the preview state, and it changes a lot in the structure of VSCode, there may still be many bugs, and there may be some compatibility problems for third-party extensions. If you find problems in use, you can go to remote development Issues to find or report, or refer to Troubleshooting in official documents to solve some common problems.

If you’re an extension developer yourself, it’s important to note that some of the past practices in remote mode may be problematic, especially some native nodejs libraries that directly access local functionality. Microsoft also lists some common scenarios that can easily lead to problems, as well as suggested solutions. See Supporting Remote Development.

Personal Feelings

According to the official assumption of Microsoft 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, I feel that SSH management is slower than local development or response, lost the sense of fluency, and I personally have no particularly strong requirements for the above scenarios, so remote development for me, at least for the moment, is not significant. However, it needs to be admitted that this method has brought a lot of imagination space, and it is also possible to see other more useful ways of playing in the future, so it is still a direction worthy of attention.

However, from an architectural point of view, I have some concerns about this extension. The main problem is complexity. The main problems I see include:

  • At present, the level of VSCode settings is quite complex, and it can be seen from the official Issue that due to the too many branches of this architecture and the difficulty of management, some problems should be more difficult to deal with, and even Microsoft developers can not give a clear answer. And the remote development mode will make this structure more complex, which is worse.
  • For extended local/remote classification, it also brings additional complexity and is not intuitive enough for extended management.
  • It also imposes an additional burden on extension developers, who may be totally unable to work in remote mode, and need to know some trivial technical details. Raising the threshold for expanding developers may be detrimental to the flourishing ecosystem of VSCode.

In the long run, is it better for remote development to be a separate product? Uh – actually I don’t know.

On Fundebug

Fundebug focuses on real-time BUG monitoring of JavaScript, WeChat applets, WeChat games, Alipay applets, React Native, Node.js and Java online applications. Since the official launch of Double Eleventh in 2016, Fundebug has dealt with a total of 1 billion + errors. Payment customers include Sunshine Insurance, Walnut Programming, Lychee FM, Palm 1-to-1, Weimai, Youth League and many other brand enterprises. Welcome to try it out for free!