VS Code online and networked

“Remote” editing

Remote edits code in particular environments from a local VS Code instance - including spinning up containers or SSH sessions, so that your editor and execution environments can be different. The remote execution environments can be elsewhere on the internet, or they can be local VMs, which is why I have “scare quotes” around the word “remote”. VS Code tries hard to make this seamless, installing some helper files on the remote side that interact smoothly with the local side. Occasionally some extensions will not work gracefully across the barrier between local and remote practices but for most of my workflows this problem does not arise. This is generally the easiest and most mainstream option, and I use it all the time.

This is best explained by using the tutorial examples.

Also I wrote one about getting remote debugging for python working, see below.

Pro tip: remote editing via unreliable or intermittent network connection can be a drag. There is no universal Persistent SSH session solution at time of writing. It would be nice if it worked over eternal terminal but it does not. However, Christopher LaPointe’s solution using tmux seems OK for now.

tl;dr:

{
  "terminal.integrated.profiles.linux": {
    "tmux": {
      "path": "/usr/bin/tmux",
      "args": [
        "new-session",
        "-A",
        "-s",
        "vscode-${workspaceFolderBasename}"
      ],
    },
  },
  "terminal.integrated.defaultProfile.linux": "tmux",
  "remote.SSH.defaultForwardedPorts": [
    {
      "localPort": 9002,
      "remotePort": 9002,
      "name": "SA"
    }
  ],
}

VS Code server

Slightly weirder: run a server process that makes VS Code accessible to you in a browser. No local copy of VS Code is required; you use a browser window for everything.

I have not had need of this yet, because any scenario where I have HTTPS browser access to a remote server, I have also had SSH access and so it has been easier to use the VS Code Remote setup.

However, a completely browser-based IDE might be useful in some circumstances: in exotic devops scenarios, through painful firewalls, when working from a thin client, something like that?

There are at least two forks of VS code designed to be a server-side editor.

Code-server by Coder: The Developer Workspace Platform seems actively maintained and popular. AFAICT it is Linux-only.

Alternatively, gitpod-io/openvscode-server seems very similar and has an explanatory blurb:

VS Code has traditionally been a desktop IDE built with web technologies. A few years back, people started patching it in order to run it in a remote context and to make it accessible through web browsers. These efforts have been complex and error prone, because many changes had to be made across the large code base of VS Code.

Luckily, in 2019 the VS Code team started to refactor its architecture to support a browser-based working mode. While this architecture has been adopted by Gitpod and GitHub, the important bits have not been open-sourced, until now. As a result, many people in the community still use the old, hard to maintain and error-prone approach.

At Gitpod, we’ve been asked a lot about how we do it. So we thought we might as well share the minimal set of changes needed so people can rely on the latest version of VS Code, have a straightforward upgrade path and low maintenance effort.

Google Cloud

Does this use the same stack as the previous ones? Maybe. GoogleCloudPlatform/cloud-code-vscode: Cloud Code for Visual Studio Code: Issues, Documentation and more

Cloud Code for VS Code brings the power and convenience of IDEs to cloud-native Kubernetes and Cloud Run application development. Cloud Code works with Google’s command-line container tools like skaffold and kubectl under the hood, providing local, continuous feedback on your project as you build, edit, and run your applications locally or in the cloud.

Collaborative editing

A different type of networking: Not using my IDE to access remote files, but using my local IDE to share the editing experience with others. Many users can access the same VS code session at the same time and collaborate on the same code edits (not just, say, the same files). There is a real-time collaboration extension called liveshare

Welcome to Visual Studio Live Share! Live Share enables you to collaboratively edit and debug with others in real time, regardless of the programming languages you're using or app types you're building. You can instantly and securely share your current project, start a joint debugging session, share terminal instances, forward localhost web apps, have voice calls, and more!

Unlike traditional pair programming, Visual Studio Live Share allows developers to work together, while retaining their personal editor preferences (e.g. theme, keybindings), as well as having their own cursor. This allows you to seamlessly transition between following one another, and being able to explore ideas/tasks on your own. This ability to work together and independently provides a collaboration experience that feels much like in-person collaboration.

Live Share is built using revolutionary architecture and concepts that manifest as powerful features for our users. To learn about those features, see Live Share features.

TIP: Did you know that you can now join a Live Share session from the browser? This means, you no longer need to install a desktop client to collaborate! Just click on the link shared with you and you can get a full-fidelity VS Code editor experience in the browser. Learn more here.

Case study: Remote python debugger

Having said that everything is seamless, there are in fact edge cases where there divide between what is here on the client and what is there on the remote server, becomes important. One of those cases is interactive debugging.

Here is a worked example of what I needed to do to get a remote python debugger working from my local machine. Finding out why code that works locally does not work in the actual target deploy environment.

First need to install the debugpy package in our project. How to install depends how we are managing your python environment, but it will probably be one of these:

pip install debugy    ## 👈🏻 this one for me
conda install debugpy
poetry add debugpy

Now I choose a network port for the debugger.¹ This port needs to be unique to me (in the sense that no-one else on the remote machine should be using it) and it should be between 1024 and 65535. For simplicity’s sake I will assume the port is 48888, but I would recommend against that number for you because someone else might have copy-pasted these instructions and got there first, if you are using a shared machine. (Although not me; I use different port numbers in reality, this is just a tutorial example).

Next, we do a one-time setup of VS Code to know that it should look for that port by finding the debug tab in VS Code and adding a configuration.

This will open launch.json into which we can add a configuration for a remote attach debugger:

{
  "name": "Attach",
  "type": "python",
  "request": "attach",
  "connect": {
    "host": "127.0.0.1",
    "port": 48888
  },
  "pathMappings": [
    {
     "localRoot": "${workspaceFolder}",
     "remoteRoot": "."
   }
 ]
}

This part is clunky, but after one-time setup everything goes smoothly. VS Code will do all the remaining necessary networking by magic.

So NOW WE ARE READY TO DEBUG. Almost. We still need to load up our code on the server to USE the debugpy module. Two options here.

Firstly, we could invoke the code from the vs code terminal like this:

python -m debugpy --listen 0.0.0.0:48888 ./myscript.py

Alternatively, we could load and execute the debugging system inside myscript.py:

import debugpy
debugpy.listen(('0.0.0.0', debug))
debugpy.wait_for_client()

Either way, VS code will detect what I am doing and magically open up an SSH tunnel from here to there. Now, if you did the wait_for_client thing, the code will pause and wait for a debugger connection.

OK great, so now I select that debug configuration I created earlier in order to get my debugger to connect

I was stuck for ages on this. but now I ALSO NEED TO CLICK THE GREEN TRIANGLE or it doesn’t start. And then… That’s it. we are done.

The debugger will show what is happening in general, but it is especially useful when

1. we hit a line that raises an exception, or
2. the code hits the line breakpoint() which will cause the debugger to drop into the code right there.

How does the debugger work? I do not need to explain because microsoft has already done that. But tl;dr there is now a lot of information about my running code, a graph of the current call stack, a little tab to inspect the current value of variables etc.

Firewall rules we need

Pro tip. for use behind a firewall, requires the following whitelist exceptions:

For github copilot:

• vscode-auth.github.com
• api.github.com
• copilot-proxy.githubusercontent.com

In addition it will be easier to install extensions with the following exceptions

• marketplace.visualstudio.com
• vscode.blob.core.windows.net
• *.vo.msecnd.net
• *.gallerycdn.vsassets.io
• download.microsoft.com (only some extensions)
• download.visualstudio.microsoft.com (only some extensions)

Liveshare requires

• *.online.visualstudio.com
• *.liveshare.vsengsaas.visualstudio.com:443

A list of miscellaneous URLS that the VSCode likes includes

• update.code.visualstudio.com - Visual Studio Code download and update server
• code.visualstudio.com - Visual Studio Code documentation
• go.microsoft.com - Microsoft link forwarding service
• vscode.blob.core.windows.net - Visual Studio Code blob storage, used for remote server
• marketplace.visualstudio.com - Visual Studio Marketplace
• *.gallery.vsassets.io - Visual Studio Marketplace
• *.gallerycdn.vsassets.io - Visual Studio Marketplace
• rink.hockeyapp.net - Crash reporting service
• bingsettingssearch.trafficmanager.net - In-product settings search
• vscode.search.windows.net - In-product settings search
• raw.githubusercontent.com - GitHub repository raw file access
• vsmarketplacebadges.dev - Visual Studio Marketplace badge service
• az764295.vo.msecnd.net - Visual Studio Code download CDN
• download.visualstudio.microsoft.com - Visual Studio download server, provides dependencies for some VS Code extensions (C++, C#)
• vscode-sync.trafficmanager.net - Visual Studio Code Settings Sync service
• vscode-sync-insiders.trafficmanager.net - Visual Studio Code Settings Sync service (Insiders)
• vscode.dev - Used when logging in with GitHub or Microsoft for an extension or Settings Sync
• default.exp-tas.com - Visual Studio Code Experiment Service, used to provide experimental user experiences