ist jetzt verfügbar! Lesen Sie über die neuen Funktionen und Fehlerbehebungen vom November.

Remote Development FAQ

Dieser Artikel behandelt häufig gestellte Fragen zu jeder der Visual Studio Code Remote Development-Erweiterungen. Weitere Details zur Einrichtung und Verwendung der jeweiligen Funktionen finden Sie in den Artikeln zu SSH, Containern und WSL. Oder probieren Sie die einführenden Tutorials aus, um schnell in einer Remote-Umgebung einsatzbereit zu sein.

Für Fragen zu GitHub Codespaces lesen Sie die GitHub Codespaces-Dokumentation.

Allgemein

Was ist Visual Studio Code Remote Development?

Das Visual Studio Code Remote Development-Erweiterungspaket ermöglicht es Ihnen, jeden Ordner in einem Container, auf einem Remote-Computer (über SSH) oder im Windows Subsystem for Linux zu öffnen und die vollständigen Funktionen von VS Code zu nutzen. Das bedeutet, dass VS Code eine lokale Entwicklungserfahrung auf höchstem Niveau bieten kann – einschließlich vollständiger IntelliSense (Vervollständigungen), Debugging und mehr –, unabhängig davon, wo sich Ihr Code befindet oder gehostet wird.

Welche Vorteile bietet VS Code Remote Development im Vergleich zur lokalen Bearbeitung?

Einige Vorteile der Remote-Entwicklung sind:

  • Bearbeiten, Erstellen oder Debuggen auf einem anderen Betriebssystem als dem, das Sie lokal ausführen.
  • Entwickeln in einer Umgebung, die der Ziel-Deployment-Umgebung entspricht.
  • Verwenden von größerer oder spezialisierterer Hardware als Ihr lokaler Computer für die Entwicklung.
  • Die Möglichkeit, Code zu bearbeiten, der an einem anderen Ort gespeichert ist, z. B. in der Cloud oder beim Kunden.
  • Trennung von Entwicklungsumgebungen zur Vermeidung von Konflikten, Verbesserung der Sicherheit und Beschleunigung der Einarbeitung.

Im Vergleich zur Verwendung eines Netzwerklaufwerks oder der Synchronisierung von Dateien bietet VS Code Remote Development eine dramatisch bessere Leistung sowie eine bessere Kontrolle über Ihre Entwicklungsumgebung und Werkzeuge.

Wie stehen die Remote Development-Erweiterungen zu GitHub Codespaces in Beziehung?

GitHub Codespaces ist ein Dienst, der verwaltete, Cloud-gehostete Entwicklungsumgebungen bereitstellt, auf die sowohl von VS Code als auch von einem neuen browserbasierten Editor zugegriffen werden kann. Der Dienst ermöglicht es VS Code und dem browserbasierten Editor auch, auf selbst gehostete Umgebungen (Desktop oder Server) zuzugreifen, ohne dass ein SSH-Server oder sogar eine direkte Netzwerkroute erforderlich ist. Sie können mehr in der GitHub Codespaces-Dokumentation lesen.

Obwohl die Remote Development- und Codespaces-Erweiterungen Technologie und Funktionen gemeinsam nutzen, werden die Remote Development-Erweiterungen separat veröffentlicht und können unabhängig von GitHub Codespaces betrieben werden.

Wie funktionieren die Remote Development-Erweiterungen?

Visual Studio Code Remote Development ermöglicht Ihrer lokalen VS Code-Installation die transparente Interaktion mit Quellcode und Laufzeitumgebungen auf anderen Maschinen (virtuell oder physisch), indem die Ausführung bestimmter Befehle auf einen "Remote-Server" verschoben wird. Der VS Code Server wird von VS Code schnell installiert, wenn Sie sich mit einem Remote-Endpunkt verbinden, und kann Erweiterungen hosten, die direkt mit dem Remote-Arbeitsbereich, der Maschine und dem Dateisystem interagieren.

Architecture summary

Weitere Details zur Unterstützung von Erweiterungen finden Sie unter Supporting Remote Development.

Wie sichern die Remote Development-Erweiterungen den Zugriff auf eine Remote-Maschine, VM oder einen Container?

Visual Studio Code Remote Development verwendet bekannte, vorhandene Transports wie die sichere Shell (SSH) zur Authentifizierung und zur Sicherung des Datenverkehrs. Außer den von diesen bekannten, sicheren Transporten verwendeten Ports müssen keine Ports öffentlich geöffnet werden.

Der injizierte VS Code Server wird als derselbe Benutzer ausgeführt, mit dem Sie sich bei der Maschine angemeldet haben. Dies stellt sicher, dass VS Code und seine Erweiterungen keine unangemessenen erhöhten Zugriffe ohne Erlaubnis erhalten. Der Server wird von VS Code gestartet und gestoppt und ist nicht in Benutzer- oder globalen Anmelde- oder Startskripten verdrahtet. VS Code verwaltet den Lebenszyklus des Servers, sodass Sie sich keine Sorgen machen müssen, ob er läuft oder nicht.

Kann der VS Code Server eigenständig installiert oder verwendet werden?

Nein. Der VS Code Server ist eine Komponente der Remote Development-Erweiterungen und wird von einem VS Code-Client verwaltet. Er wird von VS Code automatisch installiert und aktualisiert, wenn er sich mit einem Endpunkt verbindet. Wenn er separat installiert wird, könnte er schnell veraltet sein. Er ist nicht für die Verwendung durch andere Clients bestimmt oder lizenziert.

Welche Konnektivitätsanforderungen hat der VS Code Server?

Die Installation des VS Code Servers erfordert, dass Ihr lokaler Computer ausgehende HTTPS-Verbindungen (Port 443) hat zu

  • update.code.visualstudio.com
  • vscode.download.prss.microsoft.com

Standardmäßig versucht Remote - SSH, die Datei auf dem Remote-Host herunterzuladen und greift auf das Herunterladen des VS Code Servers lokal zurück und überträgt ihn remote, sobald eine Verbindung hergestellt ist. Sie können dieses Verhalten mit der Einstellung remote.SSH.localServerDownload ändern, um immer lokal herunterzuladen und dann zu übertragen oder nie lokal herunterzuladen.

Die Dev Containers-Erweiterung lädt immer lokal herunter und überträgt sie in den Container.

Sie können Erweiterungen manuell ohne Internetverbindung über den Befehl Erweiterungen: Aus VSIX installieren... installieren. Wenn Sie jedoch das Erweiterungsfeld oder devcontainer.json zum Installieren von Erweiterungen verwenden, benötigen Ihr lokaler Computer und der VS Code Server ausgehende HTTPS-Verbindungen (Port 443) zu

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

Schließlich laden einige Erweiterungen (wie C#) sekundäre Abhängigkeiten von download.microsoft.com oder download.visualstudio.microsoft.com herunter. Andere (wie Visual Studio Live Share) können zusätzliche Konnektivitätsanforderungen haben. Konsultieren Sie die Dokumentation der Erweiterung für Details, wenn Sie Probleme haben.

Die gesamte andere Kommunikation zwischen dem Server und dem VS Code-Client erfolgt über die folgenden Transportkanäle, abhängig von der Erweiterung:

  • SSH: Ein authentifizierter, sicherer SSH-Tunnel.
  • Container: Dockers konfigurierter Kommunikationskanal (über docker exec).
  • WSL: Ein zufälliger lokaler Port.

Eine Liste der Orte, auf die VS Code selbst zugreifen muss, finden Sie im Artikel Netzwerkverbindungen.

Warum sehe ich meine lokalen Container nicht in der Container Tools-Erweiterung, wenn ich die Remote-Erweiterungen verwende?

Standardmäßig läuft die Container Tools-Erweiterung remote. Während dies in einigen Fällen eine sinnvolle Standardeinstellung ist, bedeutet dies, dass die Erweiterung lokale Container möglicherweise nicht anzeigt, wenn VS Code mit einem Remote-SSH-Host, Container oder WSL verbunden ist.

Sie können eine der folgenden Lösungen verwenden, um dieses Problem zu beheben:

Welche Linux-Pakete oder Bibliotheken müssen auf einem Host installiert sein, um Remote Development nutzen zu können?

Remote Development erfordert Kernel >= 4.18, glibc >=2.28 und libstdc++ >= 3.4.25. Neuere x86_64 glibc-basierte Distributionen bieten die beste Unterstützung, aber die genauen Anforderungen können je nach Distribution variieren.

Unterstützung für musl-basierte Alpine Linux ist für die Dev Containers- und WSL-Erweiterungen verfügbar, und ARMv7l (AArch32) / ARMv8l (AArch64) ist in Remote - SSH verfügbar. Native Abhängigkeiten in bestimmten Erweiterungen können jedoch dazu führen, dass sie auf nicht-x86_64 glibc-Distributionen nicht funktionieren. Beachten Sie, dass experimentelles ARMv8l (AArch64) nur in VS Code Insiders verfügbar ist.

Weitere Details finden Sie unter Remote Development mit Linux.

Kann ich den VS Code Server auf älteren Linux-Distributionen ausführen?

Ab der VS Code-Version 1.99 (März 2025) sind die von VS Code bereitgestellten vorab kompilierten Server nur mit Linux-Distributionen kompatibel, die auf glibc 2.28 oder höher basieren. Dazu gehören beispielsweise Debian 10, RHEL 8 oder Ubuntu 20.04.

VS Code wird Benutzern weiterhin ermöglichen, sich über die Remote - SSH-Erweiterung mit einem nicht unterstützten Betriebssystem (Betriebssysteme, die nicht über glibc >= 2.28 und libstdc++ >= 3.4.25 verfügen) zu verbinden, wenn ein Sysroot mit diesen erforderlichen Bibliotheksversionen bereitgestellt wird. Dieser Ansatz gibt Ihnen und Ihrer Organisation mehr Zeit, auf neuere Linux-Distributionen zu migrieren.

VS Code-Version Basisvoraussetzungen Hinweise
>= 1.99.x Kernel >= 4.18, glibc >=2.28, libstdc++ >= 3.4.25, binutils >= 2.29 <keine>
Wichtig

Dieser Ansatz ist eine technische Problemumgehung und kein offiziell unterstützter Anwendungsfall.

Befolgen Sie diese Schritte, um Ihre Umgebung für diese Problemumgehung zu konfigurieren:

  1. Erstellen Sie das Sysroot

    Wir empfehlen die Verwendung von Crosstool-ng zum Erstellen des Sysroots. Hier sind einige Beispielkonfigurationen, mit denen Sie beginnen können:

    Das folgende Beispielcontainer kann auch verwendet werden, um eine Umgebung mit installiertem Crosstool-ng zu erhalten:

    FROM ubuntu:latest

RUN apt-get update
RUN 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

# Install crosstool-ng
RUN wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.26.0.tar.bz2
RUN tar -xjf crosstool-ng-1.26.0.tar.bz2
RUN cd crosstool-ng-1.26.0 && ./configure --prefix=/crosstool-ng-1.26.0/out && make && make install
ENV PATH=$PATH:/crosstool-ng-1.26.0/out/bin

    Sobald Sie eine Umgebung mit Crosstool-ng und den relevanten Konfigurationen vorbereitet haben, führen Sie die folgenden Befehle aus, um das Sysroot zu generieren:

    mkdir toolchain-dir
cd toolchain-dir
cp <path-to-config-file> .config
ct-ng build

  2. Der VS Code Server verwendet patchelf während des Installationsprozesses, um die erforderlichen Bibliotheken aus dem Sysroot zu beziehen.

Wichtig

Es ist bekannt, dass patchelf v0.17.x zu Segfaults mit dem Remote-Server führt. Wir empfehlen die Verwendung von patchelf >=v0.18.x.

  1. Installieren Sie die patchelf-Binärdatei und das Sysroot auf dem Remote-Host.

  2. Erstellen Sie die folgenden 3 Umgebungsvariablen:

    • VSCODE_SERVER_CUSTOM_GLIBC_LINKER Pfad zum dynamischen Linker im Sysroot (verwendet für die Option --set-interpreter mit patchelf)
    • VSCODE_SERVER_CUSTOM_GLIBC_PATH Pfad zu den Bibliotheksstandorten im Sysroot (verwendet für die Option --set-rpath mit patchelf)
    • VSCODE_SERVER_PATCHELF_PATH Pfad zur patchelf-Binärdatei auf dem Remote-Host

Sie können sich nun mit der Remote - SSH-Erweiterung mit dem Remote-Host verbinden. Nach erfolgreicher Verbindung zeigt VS Code einen Dialog und eine Banner-Meldung an, dass die Verbindung nicht unterstützt wird.

Kann ich einzelne Erweiterungen statt des Erweiterungspakets installieren?

Ja. Das Remote Development-Erweiterungspaket bietet eine bequeme Möglichkeit, auf alle neuesten Remote-Funktionen zuzugreifen, sobald sie veröffentlicht werden. Sie können die einzelnen Erweiterungen jedoch jederzeit über den Marketplace oder die VS Code-Erweiterungsansicht installieren.

Wie kann ich Erweiterungseinstellungen überprüfen und konfigurieren?

Wie bei anderen Teilen von Visual Studio Code können Sie jede der Remote Development-Erweiterungen über ihre Einstellungen anpassen. Am Beispiel von Dev Containers können Sie eine Liste aller Dev Containers-Einstellungen überprüfen, indem Sie die Erweiterung in der Erweiterungsansicht öffnen (⇧⌘X (Windows, Linux Ctrl+Shift+X)) und zu Feature Contributions navigieren.

List of settings in Feature Contributions

WSL

Was ist der Vorteil der Erweiterung gegenüber der Verwendung von WSL als Terminal?

Sie können sich WSL als eine Linux-Maschine vorstellen, die unter Windows läuft, auf der Sie Linux-spezifische Frameworks/Tools (z. B. Python, Go, Rust usw.) installieren können, ohne Ihre Windows-Einrichtung zu beeinträchtigen. Sie können dann VS Code und die WSL-Erweiterung verwenden, um im Kontext dessen zu entwickeln, was in WSL installiert ist, isoliert von dem, was unter Windows installiert ist.

Sie könnten beispielsweise den Go-Stack in WSL installieren (Compiler, Debugger, Linter usw.). Wenn Sie VS Code nur unter Windows ausführen, müssen Sie denselben Go-Stack auch dort installieren, um Funktionen wie Smart Completions, Debugging und Go to Definition-Navigation zu erhalten. Und da die Sprachdienste unter Windows laufen, wissen sie nicht, was sich in WSL befindet.

Es stimmt, dass Sie Binärdateien von WSL unter Windows und umgekehrt ausführen können, aber normale VS Code-Erweiterungen wissen nicht, wie das geht. So haben wir ursprünglich das Debugging in WSL unterstützt, erkannten aber schnell, dass wir alle Erweiterungen aktualisieren müssten, um WSL zu kennen.

Wir entschieden uns stattdessen dafür, Teile von VS Code unter WSL laufen zu lassen und die Benutzeroberfläche unter Windows mit dem VS Code-Server in WSL kommunizieren zu lassen. Das ermöglicht die WSL-Erweiterung, und damit läuft die Go-Erweiterung in WSL zusammen mit den restlichen Go-Tools (Compiler, Debugger, Linter), während VS Code unter Windows läuft.

Mit diesem Ansatz funktionieren Sprachfunktionen wie Smart Completions problemlos mit dem, was sich in WSL befindet, ohne dass unter Windows etwas eingerichtet werden muss. Sie müssen sich keine Gedanken über Pfadprobleme machen oder verschiedene Versionen von Entwicklungsstacks unter Windows einrichten. Wenn Sie Anwendungen unter Linux bereitstellen, können Sie Ihre WSL-Instanzen so einrichten, dass sie Ihrer Laufzeitumgebung ähneln, während Sie trotzdem eine reichhaltige Bearbeitungsumgebung unter Windows erhalten.

Erweiterungsautoren

Was muss ich als Erweiterungsautor tun?

Die VS Code Extension API abstrahiert lokale/Remote-Details, sodass die meisten Erweiterungen ohne Änderungen funktionieren. Da Erweiterungen jedoch beliebige Node.js-Module oder Laufzeiten verwenden können, kann es Situationen geben, in denen Anpassungen erforderlich sind. Wir empfehlen, Ihre Erweiterung zu testen (insbesondere in einem Container), um sicherzustellen, dass keine Updates erforderlich sind. Details finden Sie unter Supporting Remote Development.

Kann eine Erweiterung auf lokale Ressourcen oder APIs zugreifen, wenn ein Benutzer remote verbunden ist?

Wenn VS Code eine Verbindung zu einer Remote-Umgebung herstellt, werden Erweiterungen entweder als UI- oder als Workspace-Erweiterungen klassifiziert. UI-Erweiterungen laufen in einem lokalen Extension Host, können UI- oder Personalisierungsfunktionen beitragen (z. B. Themes) und haben Zugriff auf lokale Dateien oder APIs. Workspace-Erweiterungen laufen in einem Remote Extension Host zusammen mit dem Arbeitsbereich und haben vollen Zugriff auf den Quellcode, das Remote-Dateisystem und Remote-APIs. Obwohl Workspace-Erweiterungen sich nicht auf die UI-Anpassung konzentrieren, können sie auch Explorer, Ansichten und andere UI-Elemente beisteuern.

Wenn ein Benutzer eine Erweiterung installiert, versucht VS Code, den richtigen Speicherort zu ermitteln und sie basierend auf ihrem Typ zu installieren. Erweiterungen, die nicht remote ausgeführt werden müssen, wie Themes und andere UI-Anpassungen, werden automatisch auf der UI-Seite installiert. Alle anderen werden als Workspace-Erweiterungen behandelt, da sie die umfassendsten Funktionen bieten. Erweiterungsautoren können diesen Speicherort jedoch auch mit einer extensionKind-Eigenschaft in package.json überschreiben.

Wenn Ihre Erweiterung nicht wie erwartet funktioniert, gibt es Schritte, um zu überprüfen, ob sie am richtigen Speicherort ausgeführt wird oder ob sie möglicherweise eine andere extensionKind haben sollte. Siehe auch Supporting Remote Development für zusätzliche Details darüber, was Erweiterungsautoren über Remote Development und Codespaces wissen müssen.

Lizenz und Datenschutz

Location

Die Lizenzen für die VS Code Remote Development-Erweiterungen finden Sie hier:

Warum sind die Remote Development-Erweiterungen oder ihre Komponenten nicht Open Source?

Die Visual Studio Code Remote Development-Erweiterungen und ihre zugehörigen Komponenten verwenden einen offenen Planungs-, Issue- und Feature-Request-Prozess, sind aber derzeit nicht Open Source. Die Erweiterungen teilen sich Quellcode, der auch in vollständig verwalteten Remote-Entwicklungsdiensten wie GitHub Codespaces und ihren zugehörigen Erweiterungen verwendet wird.

Siehe die Artikel Unterschiede zwischen dem Repository und Visual Studio Code und Microsoft Extension Licenses für weitere Informationen.

Gibt es Einschränkungen, wo die Remote Development-Erweiterungen eine Verbindung herstellen können?

Sie können die Erweiterungen sowohl für den persönlichen als auch für den geschäftlichen Gebrauch verwenden, um eine Verbindung zu Ihren eigenen physischen Maschinen, virtuellen Maschinen oder Containern herzustellen. Diese können lokal, in Ihrer eigenen privaten Cloud oder Ihrem Rechenzentrum, in Azure oder bei anderen Cloud-/Nicht-Cloud-Hosting-Anbietern stehen. Sie dürfen keine öffentlichen Produkte oder Dienstleistungen auf der Grundlage der Erweiterungen oder ihrer zugehörigen Komponenten aufbauen (siehe nächste Frage).

Kann ich die VS Code Remote Development-Erweiterungen verwenden, um mein eigenes Produkt oder meine eigene Dienstleistung zu erstellen?

Sie können die Erweiterungen mit Ihren eigenen internen oder privaten Diensten verwenden. Sie dürfen keinen öffentlichen oder kommerziellen Dienst auf der Grundlage der VS Code Remote Development-Erweiterungen oder ihrer zugehörigen Komponenten (z. B. VS Code Server) erstellen. Sie dürfen keine anderen Erweiterungen erstellen, die die Remote Development-Erweiterungen erweitern oder manipulieren. Obwohl die Lizenz besagt, dass Sie "die Software nicht als eigenständiges oder integriertes Angebot bereitstellen oder sie mit einer Ihrer Anwendungen kombinieren dürfen, damit andere sie nutzen können", dürfen Sie dokumentieren, wie die Erweiterungen in Verbindung mit Ihrem Dienst verwendet werden.

Kann ich den VS Code Server in meinem eigenen öffentlichen Dienstangebot neu verpacken oder wiederverwenden?

Nein. Die Lizenz besagt, dass Sie "die Software nicht als eigenständiges oder integriertes Angebot bereitstellen oder sie mit einer Ihrer Anwendungen kombinieren dürfen, damit andere sie nutzen können", was bedeutet, dass Sie keine öffentlichen Produkte oder Dienstleistungen auf der Grundlage des VS Code Servers erstellen dürfen.

Ich habe eine Frage dazu, ob ich die Erweiterungen für X verwenden kann. Wen kann ich fragen?

Bitte reichen Sie ein Issue ein.

DSGVO und VS Code Remote Development

Die VS Code Remote Development-Erweiterungen folgen den DSGVO-Richtlinien wie Visual Studio Code selbst. Weitere Details finden Sie in der allgemeinen FAQ.

Fragen oder Feedback

Haben Sie eine Frage oder Feedback?

12/10/2025
© . This site is unofficial and not affiliated with Microsoft.