VS Code online and networked

January 25, 2018 — September 23, 2024

computers are awful together
faster pussycat
plain text
UI
workflow
Figure 1

Here are tips for using VS Code as a collaborative cloud-friendly editor, in several senses.

1 “Remote”

Remote edits code over a network channel to a remote machine from a local VS Code desktop window Figure 2. 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 executables on the remote side that interact smoothly with the local side so that the two may be smushed together. Occasionally, some extensions will not work gracefully across the barrier between local and remote, but for most of my workflows the problem does not arise. VS Code remote is generally (although not strictly) feature-superior to remote jupyter usage.

Figure 2

Use in practice is best explained by using the tutorial examples.

Tutorial Description
Remote via SSH Connect to remote and virtual machines with Visual Studio Code via SSH.
Work in WSL Run Visual Studio Code in Windows Subsystem for Linux.
Develop in Containers Run Visual Studio Code in a Docker Container.
GitHub Codespaces Connect to a codespace with Visual Studio Code.

Also, I wrote about getting remote debugging for python working in a fiddly environment, see below.

Pro tip: remote editing via unreliable or intermittent network connection can be a drag over SSH. 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 provides a bandaid; and the Microsoft Dev Tunnel thing is anecdotally more robust over unreliable connections.

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"
    }
  ],
}
Jupyter notebooks and tmux

Jupyter Notebook can interact badly with VS code remote, losing data if there is a buggy extension installed. (See also.)

I get the error “Failed to parse remote port from server”

Me too. It seems to be something to do with stale lock files:

rm .vscode-server/bin/**/vscode-remote-lock.*
Apparently my (remote) home folder is now full

If things crash, or if we switch from vs code to vs code insiders build, it can leave stake crap around.

I’m pretty sure that the ones that end in .bak or .locked are pointless.

rm -r .vscode-server-insiders* # or
rm -r .vscode-server*

1.1 Dev tunnels

Microsoft’s Dev Tunnels do not appear to be an SSH tool, but behave similarly, but claim to be more persistent over unreliable connections. They appear to be supported by VS Code as a means of remote access.

Microsoft dev tunnels background:

For an example of use with VS Code, see the VS Code + Tunnels docs and, e.g. Port forwarding local services with VS Code.

2 VS Code server

I have not tested this configuration recently.

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 VS Code Server mode 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 several supported configs

Mainline VS Code server:

There are also two community-maintained forks:

I do not know the difference between the affordances of all these options.

3 Google Cloud

We can use VS Code as a remote APU for google cloud, apparently. 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.

4 Google Colab

Distinct, both in billing and API, from generic google cloud, but also possible?

5 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.

6 Remote python debugger

Having said that everything is seamless, there are in fact edge cases where the 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, install the debugpy package in our project. How to install depends on how we are managing your python environment, but it will probably be one of these:

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

Now I choose a network port for the debugger.1 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, Figure 3 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.

Figure 3:

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.

OK! Almost there. 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', 48888))
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

Figure 4

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.

7 Firewall rules we need

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

Liveshare requires

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

For github copilot:

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

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

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)

Footnotes

  1. Technically we need to choose a port on the local AND remote machine, and these can be different, but why do that?↩︎