本站点文档内容均翻译自code.visualstudio.com,仅供个人学习,如有差异请以官网为准。

远程开发常见问题

本文涵盖了每个Visual Studio Code 软件开发工具远程开发扩展的常见问题。请参阅SSH容器WSL文章,以获取有关设置和使用各自功能的更多详细信息。或者,尝试入门教程,以帮助您快速在远程环境中运行。

关于GitHub Codespaces的问题,请参阅GitHub Codespaces 文档

一般

什么是Visual Studio Code远程开发?

Visual Studio Code远程开发扩展包允许您在容器中、远程机器上(通过 SSH)或在 Windows 子系统 for Linux 中打开任何文件夹,并利用 VS Code 的全部功能。这意味着 VS Code 可以提供本地质量的开发体验——包括完整的 Intellisense(代码补全)、调试等——无论您的代码位于何处或托管在何处。

VS Code 跨远程开发与本地编辑相比有哪些优势?

远程开发的一些好处包括:

  • 能够在本地运行的操作系统不同的情况下进行编辑、构建或调试。
  • 能够在与目标部署环境相匹配的环境中进行开发。
  • 使用比本地机器更大或更专业的硬件进行开发。
  • 编辑存储在其他位置(例如云端或客户现场)的代码的能力。
  • 将开发环境隔离,以避免冲突、提高安全性并加快入职速度。

与使用网络共享或同步文件相比,VS Code 远程开发提供了更好的性能,并且对开发环境和工具具有更好的控制。

远程开发扩展与 GitHub Codespaces 有什么关系?

GitHub Codespaces 是一个服务,提供可通过 VS Code 和新的基于浏览器的编辑器访问的托管云开发环境。该服务还允许 VS Code 和基于浏览器的编辑器访问自托管环境(桌面或服务器),而无需要求 SSH 服务器或甚至直接网络路由。您可以在 GitHub Codespaces 文档 中阅读更多内容。

虽然“远程开发”和“Codespaces”扩展共享技术和功能,“远程开发”扩展是单独发布的,并且可以独立于GitHub Codespaces运行。

远程开发扩展如何工作?

Visual Studio Code 远程开发允许您的本地 VS Code 安装通过将某些命令的执行移动到“远程服务器”来透明地与另一台机器(无论是虚拟的还是物理的)上的源代码和运行时环境互动。 VS Code Server 是 VS Code 在您连接到远程端点时快速安装的,可以托管直接与远程工作区、机器和文件系统互动的扩展。

架构概述

参见支持远程开发以获取有关扩展的更多详细信息。

远程开发扩展如何确保对远程机器、VM 或容器的访问安全?

Visual Studio Code 远程开发使用现有的、广为人知的传输方式,如安全外壳来认证和保护流量。除了这些广为人知的安全传输所使用的端口外,不需要额外公开开放端口。

注入的 VS Code Server 以您登录机器时使用的相同用户身份运行,确保 VS Code 和其扩展在未经许可的情况下不会被授予不适当的提升访问权限。服务器由 VS Code 启动和停止,并且不会与任何用户或全局登录或启动脚本连接。VS Code 管理服务器的生命周期,因此您无需担心它是否在运行。

VS Code Server 可以单独安装或使用吗?

不。VS Code Server 是远程开发扩展的一部分,由 VS Code 客户端管理。当 VS Code 连接到一个端点时,它会自动安装和更新。如果单独安装,可能会很快变得过时。它不打算或没有授权供其他客户端使用。

VS Code Server 的连接要求是什么?

安装 VS Code Server 需要您的本地机器具有到以下地址的 outbound HTTPS (端口 443) 连接:

  • 更新.code.visualstudio.com
  • vscode下载.prss.microsoft.com

默认情况下,Remote - SSH 将尝试在远程主机上下载,并在建立连接后回退到在本地下载 VS Code Server 并远程传输。您可以使用以下选项更改此行为

远程.SSH.本地服务器下载
  • 在 VS Code 中打开
  • 在 VS Code Insiders 中打开
设置为始终本地下载并传输,或者从不本地下载。

Dev Containers 扩展始终在本地下载并传输到容器中。

您可以在没有互联网连接的情况下手动安装扩展,使用 扩展:从 VSIX 安装... 命令,但如果您使用扩展面板或 devcontainer.json要安装扩展,您的本地机器和 VS Code Server 需要访问以下内容的 outbound HTTPS (端口 443):

  • marketplace.visualstudio.com
  • *.gallerycdn.vsassets.io(Azure CDN)

最后,一些扩展(如 C#)从下载次要依赖项download.microsoft.comdownload.visualstudio.microsoft.com其他(如Visual Studio Live Share)可能有额外的连接要求。如果你遇到问题,请查阅扩展的文档以获取详细信息。

所有其他服务器和VS Code客户端之间的通信都是通过以下传输通道完成的,具体取决于扩展:

  • SSH:一个经过身份验证的、安全的SSH隧道。
  • 容器:Docker 的配置通信通道 (通过docker 执行)。
  • WSL:一个随机的本地端口。

您可以在网络连接文章中找到 VS Code 本身需要访问的位置列表。

为什么在使用远程扩展时,我在容器工具扩展中看不到我的本地容器?

默认情况下,Container Tools 扩展将远程运行。虽然在某些情况下这是合理的默认设置,但它意味着当 VS Code 连接到远程 SSH 主机、容器或 WSL 时,扩展可能不会显示本地容器。

您可以使用以下解决方案之一来解决此问题:

在主机上需要安装哪些 Linux 软件包或库才能使用远程开发?

远程开发需要内核 >= 4.18,glibc >= 2.28,和 libstdc++ >= 3.4.25。最近的基于 glibc 的 x86_64 发行版具有最佳支持,但具体要求可能因发行版而异。

对基于musl的Alpine Linux的支持已提供给开发容器和WSL扩展,并且在Remote - SSH中提供ARMv7l (AArch32) / ARMv8l (AArch64)。然而,某些扩展中的原生依赖项可能导致它们在非x86_64 glibc发行版上无法正常工作。请注意,实验性的ARMv8l (AArch64)仅在VS Code Insiders中提供。

参见 使用 Linux 进行远程开发 以获取更多详细信息。

我可以在较旧的 Linux 发行版上运行 VS Code Server 吗?

从 VS Code 1.99 版本(2025年3月)开始,VS Code 发布的预构建服务器仅与基于 glibc 2.28 或更高版本的 Linux 发行版兼容。例如,包括 Debian 10、RHEL 8 或 Ubuntu 20.04。

VS Code 仍然允许用户通过Remote - SSH扩展连接到不被 VS Code 支持的操作系统(没有 glibc >= 2.28 和 libstdc++ >= 3.4.25 的操作系统),前提是提供了具有这些所需库版本的 sysroot。这种方法为您和您的组织赢得了更多时间来迁移到更新的 Linux 发行版。

VS Code 版本 基本要求 笔记
>= 1.99.x 内核 >= 4.18,glibc >= 2.28,libstdc++ >= 3.4.25,binutils >= 2.29 <无>
重要

这种方法是一种技术上的变通方案,并不是官方支持的使用场景。

请按照以下步骤配置您的环境以使用此解决方法:

  1. 构建sysroot

    我们建议使用Crosstool-ng来构建sysroot。以下是一些您可以开始使用的示例配置:

    以下示例容器也可以用于安装Crosstool-ng的环境:

    来自 ubuntu:最新
    
    运行 apt-get update
    运行 apt-get install -y gcc g++ gperf bison flex texinfo help2man make libncurses5-dev \
    python3-dev autoconf automake libtool libtool-bin gawk wget bzip2 xz-utils unzip \
    patch rsync meson ninja-build
    
    # 安装 crosstool-ng
    运行 wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.26.0.tar.bz2
    运行 tar -xjf crosstool-ng-1.26.0.tar.bz2
    运行 cd crosstool-ng-1.26.0 && ./configure --prefix=/crosstool-ng-1.26.0/out && make && make install
    环境变量 PATH=$PATH:/crosstool-ng-1.26.0/out/bin
    

    一旦你有了一个环境,并且准备好了Crosstool-ng和相关的配置,运行以下命令来生成sysroot

    创建目录 toolchain-dir
    进入目录 toolchain-dir
    复制 <配置文件路径> .config
    ct-ng 构建
    
  2. VS Code 服务器在安装过程中使用 patchelf 来从 sysroot 消耗所需的库。

重要

补丁精灵v0.17.x已知会导致与远程服务器的段错误,我们建议使用patchelf>=v0.18.x

  1. 在远程主机上安装 patchelf 二进制文件和 sysroot

  2. 创建以下3个环境变量:

    • VSCODE_SERVER_CUSTOM_GLIBC_LINKER 系统根目录下的动态链接器路径 (用于 --设置解释器 选项与 patchelf
    • VSCODE_SERVER_CUSTOM_GLIBC_PATH 系统根目录下库的位置的路径(用作 --设置运行路径 选项与 patchelf
    • VSCODE_SERVER_PATCHELF_PATH 远程主机上 patchelf 二进制文件的路径

您现在可以使用远程 - SSH扩展来连接远程服务器。成功连接后,VS Code将显示一个对话框和横幅消息,说明该连接不受支持。

我可以单独安装扩展而不是扩展包吗?

是的。Remote Development 扩展包 提供了一种方便的方法,使您能够访问所有最新的远程功能。然而,您可以随时从市场或 VS Code 扩展视图中安装单个扩展。

如何查看和配置扩展设置?

正如 其他部分的Visual Studio Code一样,您可以定制每个远程开发扩展的设置。以开发容器为例,您可以通过在扩展视图中打开扩展(⇧⌘X(Windows, Linux Ctrl+Shift+X),并导航到 功能贡献来查看所有开发容器的设置:

功能贡献中的设置列表

适用于 Linux 的 Windows 子系统

使用这个扩展与直接使用WSL作为终端相比有什么优势?

你可以将WSL视为在Windows上运行的Linux机器,你可以在其中安装特定于Linux的框架/工具(例如Python、Go、Rust等),而不会影响你的Windows设置。然后,你可以使用VS Code和WSL扩展在WSL中安装的上下文中进行开发,同时与Windows上安装的内容隔离。

例如,你可能会在WSL(编译器、调试器、检查器等)中安装Go堆栈。如果你只在Windows上运行VS Code,你必须也在那里安装相同的Go堆栈,以获得诸如智能补全、调试、Go to Definition导航等功能。由于语言服务在Windows上运行,它们不知道WSL中的内容。

确实,你可以在Windows中运行WSL中的二进制文件,反之亦然,但常规的VS Code扩展不知道如何做到这一点。这就是我们开始支持WSL调试的方式,但很快就意识到我们必须更新所有扩展以了解WSL。

我们决定让 VS Code 的某些部分在 WSL 中运行,并让在 Windows 上运行的用户界面与在 WSL 中运行的 VS Code 服务器进行通信。这就是 WSL 扩展所实现的,有了它,Go 扩展与其余的 Go 工具(编译器、调试器、检查器)一起在 WSL 中运行,而 VS Code 在 Windows 上运行。

通过这种方法,智能补全等语言功能可以针对WSL中的内容自动工作,无需在Windows上进行任何设置。您无需担心路径问题或在Windows上设置不同版本的开发堆栈。如果您将应用程序部署到Linux,您可以设置WSL实例以看起来像您的运行时环境,同时在Windows上仍能获得丰富的编辑体验。

扩展作者

作为一名扩展作者,我需要做些什么?

VS Code 扩展 API 抽象掉了本地/远程的细节,因此大多数扩展在不修改的情况下应该可以正常工作。然而,由于扩展可以使用任何他们想要的 node 模块或运行时,存在需要进行调整的情况。我们建议您在容器中测试您的扩展,以确保不需要更新。详情请参阅支持远程开发

当用户通过远程连接时,扩展程序可以访问本地资源或API吗?

当 VS Code 连接到远程环境时,扩展分为 用户界面工作区 扩展。用户界面扩展在 本地扩展主机 中运行,可以贡献用户界面或个性化功能(例如主题),并可以访问本地文件或 API。工作区扩展在 远程扩展主机 中运行,并且可以访问工作区,可以完全访问源代码、远程文件系统和远程 API。虽然工作区扩展不专注于用户界面定制,但它们也可以贡献资源管理器、视图和其他用户界面元素。

当用户安装一个扩展时,VS Code 会尝试根据其类型推断出正确的位置并进行安装。像主题和其他用户界面定制这样的不需要远程运行的扩展会自动安装在用户界面侧。所有其他扩展被视为工作区扩展,因为它们是最功能齐全的。然而,扩展作者也可以通过一个 来覆盖这个位置扩展类型物业在package.json输入:.

如果你的扩展没有按预期工作,有步骤可以检查它是否在正确的位置运行或是否应该有一个不同的扩展类型。另见支持远程开发,以获取有关远程开发和Codespaces的扩展作者需要了解的详细信息。

许可和隐私

位置

您可以在此处找到 VS Code 远程开发扩展的许可证:

为什么远程开发扩展及其组件不是开源的?

Visual Studio Code 远程开发扩展及其相关组件使用 开放的规划、问题和功能请求过程,但目前尚未开源。这些扩展共享的源代码也用于像 GitHub Codespaces 这样的完全管理的远程开发服务及其相关扩展。

查看Visual Studio Code 和 'Code - OSS' 的差异以及Microsoft 扩展许可证文章了解更多信息。

远程开发扩展可以连接到哪些地方是否有任何限制?

您可以自由地将这些扩展用于个人或公司目的,以连接到您自己的物理机、虚拟机或容器。这些机器可以是本地的、在您自己的私有云或数据中心中的、在Azure中的,或者在其他云/非云托管提供商中。您不能在扩展或其相关组件的基础上构建公共产品或服务(请参见下一个问题)。

我可以使用 VS Code 远程开发扩展来构建自己的产品或服务吗?

您可以将这些扩展与您的内部或私人服务一起使用。您不能在 VS Code 远程开发扩展或其相关组件(例如 VS Code 服务器)的基础上构建公共或商业服务。您不能创建其他扩展,这些扩展扩展或操作远程开发扩展。虽然许可证表明您“不得将软件作为独立或集成的解决方案提供,也不得将其与任何应用程序结合供他人使用”,但您可以记录如何将扩展与您的服务结合使用。

我可以将 VS Code Server 重新包装或在我的 own 公共服务提供中重新使用吗?

不。许可证规定您不得“将软件作为独立产品或集成产品提供,或将之与您的任何应用程序结合供他人使用”,这意味着您不得在VS Code Server基础上构建公共产品或服务。

我有一个关于是否可以使用X的扩展的问题,我应该问谁?

请提交一个问题

GDPR和VS Code远程开发

VS Code 远程开发扩展遵循与 Visual Studio Code 本身相同的 GDPR 政策。请参阅常见问题获取更多详细信息。

问题或反馈

有问题或反馈吗?