Share via

Erweiterungen und Ökosystemunterstützung

  • Artikel

Eines der Hauptziele von Visual Studio Live Share ist es, Entwicklern die Zusammenarbeit mit einander zu ermöglichen, von ihrem Lieblings-, und hoch angepassten Tools. Auf diese Weise können Ad-hoc-Interaktionen häufig auftreten, während Sie visuell vertraut und ergonomische bleiben, unabhängig davon, was Sie dabei unterstützen. Um dies zu erreichen, ist es wichtig, dass Die Teilnehmer innerhalb einer Zusammenarbeitssitzung weiterhin erweiterungen verwenden können, die ihre persönlichen Vorlieben und Workflows unterstützen (z. B. Farb-/Symboldesigns, Keybindungen, Editor-Produktivitätssteigerungen).

Um die Teilnahme an einer Zusammenarbeitssitzung so sofort wie möglich zu gestalten, während sie hochproduktiv bleiben, besteht das Ziel von Visual Studio Live Share darin, Gästen die automatische Nutzung der projektspezifischen Tools zu ermöglichen, die ihr Host freigegeben hat. Auf diese Weise können Sie einfach auf einen Link klicken, Ihr Wahltool starten und mit der Zusammenarbeit beginnen, ohne zusätzliche Einrichtung. Um dies zu erreichen, ist es wichtig, dass Erweiterungen, die den kernigen Bearbeitungs-, Build- und Debugworkflow ermöglichen, transparent vom Host zum Gast "entfernt" werden, sodass Dinge wie autovervollständigen, go-to-definition und Debugging "just work" funktionieren.

Dieses Dokument behandelt den aktuellen bekannten Zustand für das riesige Erweiterungsökosystem sowie eine "Scorecard" für die oben genannten Ziele. Wenn Sie auf eine Erweiterung stoßen, die diese Kriterien nicht erfüllt und für Ihren persönlichen Workflow wichtig ist, teilen Sie uns bitte mit!

Benutzerspezifische Erweiterungen

Erweiterungen, die benutzerspezifische Anpassungen unterstützen, müssen für den Host funktionieren und für alle Gäste funktionieren. Wenn eine Erweiterung für den Host nicht ordnungsgemäß funktioniert, wäre dies eine Regression und ist wahrscheinlich ein Fehler in Visual Studio Live Share (bitte geben Sie ein Problem an, wenn eine angezeigt wird!). Wenn sich eine Erweiterung nicht wie erwartet für einen Gast verhält, kann es Änderungen an der Erweiterung selbst erfordern, und wir arbeiten mit dem Ökosystem zusammen, um diese Szenarien zu beheben/zu verbessern.

Visual Studio Code

Kategorie Beispiel(e) Gast unterstützt? Gemeinsame?
Farbdesigns One Dark Pro, Ausgabefarbizer, Regenbogenzeichenfolge, farbige Bereiche, Hervorgehobener Blockeinzug, Todo-Hervorhebung, Klammernpaar-Farbizer ✅ N/V
Symbolsätze vscode-icons, Visual Studio Classic Icons ✅ N/V
Schlüsselbindungen Vim, IntelliJ IDEA Keybindings, Emacs Friendly Keymap ✅ N/V
Codeausschnitte Angular v5 Codeausschnitte, HTML-Codeausschnitte, SVG-Symbole, Dateiheader ✅ N/A1
Organisation Settings Sync, Project Manager, Timeit, Checkpoints, TODO Parser, Favorites (), Bookmarks (❌❌) ✅2 N/A3
Produktivität GitLens, Auto-Rename Tag, Code Outline, Color Highlight, Increment Selection, Bracketeer, Image Preview, JSON Helper (Hover), Color Picker, Copy Word in Cursor, CodeMetrics (CodeLens), Git Co-Authors, JavaScript Booster (CodeActions), Turbo Console Log, Goto Next/Previous Member, Auto-Scroll, NPM Importversion (❌), Importkosten (❌) ✅2 ❌3
REPLs REST-Client, Code Runner, Quokka.js, R ✅4 ❌3
Ressourcenmanager mssql, ftp-simple, Azure Functions, Docker, Brew Services ✅5 ❌3

1Wenn ein Benutzer nicht bereits mit einem Codeausschnitt vertraut war, würde er nicht erwarten, dass er verfügbar ist, und daher ist es nicht notwendigerweise sinnvoll, sie freigegeben zu machen.

2Diese Erweiterungskategorien sind so vielfältig, dass es unmöglich ist, sie alle zu sagen. Theoretisch sollten sie jedoch die wichtigsten nachverfolgen, die nicht funktionieren.

3Diese Erweiterungskategorien können von der Zusammenarbeit profitieren, und daher benötigen wir Feedback von Endbenutzern, um das zu wissen!

4Diese erfordern, dass der Gast die Laufzeittools installiert hat (z. B. Node.js), und funktioniert, indem Code lokal ausgeführt wird.

5Diese Arbeiten funktionieren durch Herstellen einer Verbindung mit einem Server irgendeiner Art und können entweder mit zentralen Servern, Servern, die der Gast freigegeben hat, arbeiten.

Projektspezifische Erweiterungen

Host installierte Erweiterungen, die die Kernbearbeitung, Erstellung und Debugging einer Anwendung unterstützen und spezifisch für eine Sprache/Plattform/Bibliothek/SDK sind, sollten automatisch für Gäste verfügbar sein, ohne dass sie etwas installieren müssen. Auf diese Weise können Hosts ihre Umgebung einrichten, um die produktive Entwicklung eines Projekts zu unterstützen, und ihren Gästen die sofortige Teilnahme zu ermöglichen, ohne zusätzliche Voraussetzungen. Da projektspezifische Erweiterungen nicht subjektiv oder persönlich sind, können sie von Host zu Gast deterministisch geteilt werden, ohne die vertraute Umgebung eines benutzers zu beeinträchtigen.

Um projektspezifische Erweiterungen zu unterstützen, die ein Gast installiert hat, aber der Host nicht, bietet er idealerweise eine beeinträchtigte, aber funktionale Erfahrung (z. B. das Abrufen einzelner Datei intellisense, das Formatieren eines Dokuments).

Kategorie Beispiel(e) Geteilt? Gast unterstützt?
Grammatiken/ Syntaxmarkierung Fish Shell, Nginx, Vetur, DotEnv, ES6 String HTML, Todo+, Rainbow CSV ❌ ✅
Sprachdienste YAML, Path IntelliSense, ARM ✅1 ✅2
JSON-Schemas Azure-Funktionen ✅ ✅
Linter ESLint, Markdownlint, Code Spell Checker, PHPCS ✅ ✅2
Formatierer Schöner, Verschönern ✅ ✅2
Debugger Python, Debugger für Chrome ✅3 ❌4
Testen von Läufern Java Test Runner, Mocha Sidebar, Postman Runner, Jest Runner, Neptune ❌5 ✅2
Benutzerdefinierte Dateivorschauprogramme SVG Preview, GraphViz, Markdown-Bildgröße ❌ ✅
Datei-/Projektgeneratoren Azure Functions, C/C++-Projektgenerator ❌ ❌6
Anbieter der Quellcodeverwaltung SVN, Hg ❌ ❌

1Derzeit nur C# und JavaScript/TypeScript.

2Würde nur das aktuelle aktive Dokument unterstützen, da Gäste keinen lokalen Dateizugriff haben.

3Die Kerndebugging-Erfahrung wird freigegeben, jedoch werden alle gestarteten Server nicht automatisch weitergeleitet.

4Gäste verfügen nicht über eine lokale Kopie der App, daher müssen die ausgeführte App und alle Debugsitzungen auf dem Hostcomputer gestartet werden.

5Die Ausgabe eines Testlaufs würde erfordern, dass alle resultierenden Terminals, Ausgabebereiche und Fehler auch für Gäste freigegeben wurden.

6Fast alle würden das Node.js-Modul fs direkt zum Erstellen von Dateien verwenden, was nicht funktionieren würde.

Bekannte Probleme

Im Folgenden sind derzeit bekannte Erweiterungsprobleme aufgeführt, die verhindern können, dass sie im Kontext einer Zusammenarbeitssitzung (zusammen mit ihren Problemumgehungen) für Gäste arbeiten und sich daher auf ihren Workflow auswirken können:

Visual Studio Code

Problem `Reason` Problemumgehung
Verwenden des Node.js-Moduls fs zum Erkennen/Lesen von Dateien (z. B. einer Konfigurationsdatei) oder Aufzählen von Verzeichnissen (und Sie sind kein Sprachdienst). Gäste haben keinen lokalen Dateizugriff. 1. Erniedrigen Sie die Benutzerfreundlichkeit (sofern möglich).

2. Verwenden Sie die openTextDocument APIs und findFiles Arbeitsbereichs-APIs zum Lesen und Aufzählen von Dateien.
Verwenden des Node.js-Moduls fs zum Erstellen oder Schreiben von Dateien Identisch mit oben N/A Sie können die openTextDocument(Uri) API verwenden, um eine untitled Datei zu erstellen, aber Sie können sie nicht direkt im Dateisystem unter einem bestimmten Pfad speichern.
Abhängig von einer projektbündelten Bibliothek oder einem Projekttool Identisch mit oben 1. Bündeln einer Fallbackversion der Abhängigkeit mit der Erweiterung

2. Unterstützen Sie die globale Installation, um Gäste zu entsperren, wenn sie dies explizit installieren möchten.

3. Remotestatus/Aktion, wenn möglich, da der Host die richtigen Abhängigkeiten verfügbar hätte.
Verwenden des Node.js-Moduls fs zum Erstellen eines Verzeichnisses Identisch mit oben N/V
Einschränken der Funktionalität auf Dokumente, die das file Schema verwenden. Dateien auf der Gastseite verwenden das vsls Schema. Hinzufügen von Unterstützung für vsls Dokumente (Beispiel)
Verwenden der Methode und/oder Uri.fsPath/TextDocument.fileName der Uri.file Member zum Serialisieren/Analysieren von URIs Identisch mit oben Verwenden Uri.parse und Url.toString() stattdessen, die Dateischemas verwalten und respektieren (Beispiel)
Verwenden der workspace.openTextDocument Methode mit einem Dateipfad anstelle eines Uri Identisch mit oben Bereitstellen einer Uri Instanz anstelle einer unformatierten Dateipfadzeichenfolge (Beispiel)
Verwenden der workspace.rootPath Eigenschaft zum Erkennen des Vorhandenseins eines Arbeitsbereichs Die workspace.rootPath Eigenschaft ruft Uri.fsPath die erste workspaceFolder in der workspace, die das gleiche Problem wie oben erwähnt auf. Verwenden Sie die workspace.workspaceFolders Eigenschaft, um stattdessen das Vorhandensein eines Arbeitsbereichs Uri.scheme zu erkennen, und schauen Sie sich bei Bedarf die einzelnen workspaceFolderElemente an, um festzustellen, ob es lokal ist oder nicht.
Angeben eines Dokumentschemas beim Registrieren von Sprachdiensten (entweder über ein LanguageClientoder die languages.register* Methoden) Gäste erhalten die Ergebnisse des Sprachdiensts sowohl von ihren lokalen Erweiterungen als auch vom Host. Wenn beide Teilnehmer die gleiche Sprachdiensterweiterung installiert haben, sehen Gäste doppelte Einträge für bestimmte Dinge (z. B. Autovervollständigen, Codeaktionen) Beschränken der Sprachdienste auf nur file und untitled Schemas (Beispiel)
Das Überprüfen eines Dokuments vor Uri.scheme dem Auffüllen eines DiagnosticCollection Dokuments Identisch mit oben Nur generierenDiagnostics, für documents derenfile === Uri.scheme (Beispiel)
Wird beim Zurückgeben Tasks von einem benutzerdefinierten Arbeitsbereichsschema nicht auf das Arbeitsbereichsschema überprüft. TaskProvider Gäste zeigen alle Remote- und lokalen Aufgaben an und würden daher Duplikate anzeigen, wenn beide Teilnehmer dieselbe Erweiterung installiert hatten. Nur für s zurückgebenTasks, deren Uri.schemefile === (Beispiel)WorkspaceFolder

Siehe auch

Gibt es Probleme? Lesen Sie Troubleshooting oder Feedback geben.