共用方式為

延伸模組和生態系統支援

  • 發行項

Visual Studio Live Share 的主要目標之一，是讓開發人員能夠從自己最愛的工具和 高度自定義 的工具中彼此共同作業。 如此一來，臨機操作互動可能會經常發生，同時保持視覺上熟悉且符合性，而不論您有什麼説明。 若要達成此目的，共同作業會話內的參與者必須能夠繼續使用任何支援其 個人喜好設定和工作流程 的延伸模組（例如色彩/圖示主題、主要系結、編輯器生產力增強工具）。

此外，若要盡可能立即加入共同作業會話，同時保持高生產力，Visual Studio Live Share 的目標是讓來賓能夠自動利用其主機共用的專案特定工具。 如此一來，您可以直接按兩下連結、啟動您選擇的工具，並開始共同作業，而不需要任何額外的設定。 若要達成此目的，擴充功能對於核心編輯、建置和偵錯工作流程至關重要，這些延伸模組會以透明方式「遠端」從主機「遠端」到客體，讓自動完成、移至定義和偵錯「只正常運作」等專案。

本文件涵蓋廣大延伸生態系統的目前已知狀態，以及上述目標的「計分卡」。 如果您遇到不符合此準則的延伸模組，而且對您的個人工作流程至關重要，請 讓我們知道！

使用者特定擴充功能

支援使用者特定自定義的 擴充功能必須 適用於主機，而且 應該 適用於所有來賓。 如果擴充功能不適用於主機，那將會是回歸，而且可能是Visual Studio Live Share 中的Bug（如果您看到問題，請 提出問題 ！）。 如果擴充功能對來賓的行為不如預期，它可能需要 變更擴充功能本身，我們將使用生態系統來處理/改善這些案例。

Visual Studio Code

類別 範例 來賓支援？ 共同？
色彩主題 一個深色專業，輸出著色器，彩虹字元串，彩色區域，縮排區塊醒目提示，Todo 醒目提示，括號配對著色器 ✅ N/A
圖示集 vscode-icons、 Visual Studio 傳統圖示 ✅ N/A
按鍵繫結 Vim、 IntelliJ IDEA Keybindings、 Emacs Friendly Keymap ✅ N/A
程式碼片段 Angular v5 代碼段、HTML 代碼段、SVG 圖示、檔案標頭 ✅ N/A 1
Organization 設定同步、項目經理、Timeit、Checkpoints、TODO 剖析器、我的最愛 （）、書籤 （❌❌） ✅2 N/A 3
生產力 GitLens、自動重新命名標記、程式代碼大綱、色彩醒目提示、遞增選取範圍、括弧、影像預覽、JSON 協助程式（暫留）、色彩選擇器、數據指標中的複製 Word、CodeMetrics （CodeLens）、Git 共同作者、JavaScript Booster （CodeActions）、Turbo 控制台記錄、Goto Next/Previous 成員、自動捲動、NPM匯入版本 （❌）， 匯入成本 （❌） ✅2 ❌3
REPLs REST 用戶端、 程式代碼執行器、 Quokka.js、 R ✅4 ❌3
資源管理員 mssql， ftp-simple， Azure Functions， Docker， Brew Services ✅5 ❌3

1 除非使用者已經熟悉代碼段，否則他們不會預期該代碼段可供使用，因此，使其共用不一定有意義。

2 這些延伸模組類別非常多樣化，因此無法說它們全都能夠運作。然而，理論上，他們應該，我們將追蹤沒有的關鍵。

3 這些延伸模組類別可能會受益於共同作業體驗，因此我們需要使用者意見反應才能知道！

4 這些要求來賓安裝運行時間工具（例如Node.js），並在本機執行程式代碼來運作。

5 這些工作的方式是連線到某種類型的伺服器，而且可以與來賓共用的伺服器、伺服器搭配使用。

專案特定延伸模組

裝載安裝的擴充功能，可支援應用程式的核心編輯、建置和偵錯，而且專屬於語言/平臺/連結庫/SDK，應該會自動提供給來賓使用，而不需要它們安裝任何專案。 如此一來，主機就可以設定其環境以支援專案的生產力開發，並允許其來賓立即加入這些專案，而不需要額外的必要條件。 由於專案特定的擴充功能並非主觀或個人，因此可以有決定性地從主機與來賓共用，而不會影響任何人熟悉的環境。

此外，為了支援客體已安裝的專案特定擴充功能，但主機並未安裝，它們最好提供降級但功能不佳的體驗（例如取得單一檔案 Intellisense，能夠格式化檔）。

類別 範例 共用？ 來賓支援？
文法/語法醒目提示 Fish Shell、Nginx、Vetur、DotEnv、ES6 String HTML、Todo+、彩虹 CSV ❌ ✅
語言服務 YAML、 路徑 Intellisense、 ARM ✅1 ✅2
JSON 架構 Azure Functions ✅ ✅
Linters ESLint、Markdownlint、程式代碼拼字檢查程式、PHPCS ✅ ✅2
格式器 美化， 美化 ✅ ✅2
偵錯工具 Python， 適用於 Chrome 的調試程式 ✅3 ❌4
測試執行器 Java 測試執行器、 Mocha 提要欄、 Jest Runner、 Neptune ❌5 ✅2
自定義檔案預覽工具 SVG 預覽、 GraphViz、 Markdown 影像大小 ❌ ✅
檔案/項目產生器 Azure Functions、 C/C++ 項目產生器 ❌ ❌6
原始檔控制提供者 SVN、 Hg ❌ ❌

1 目前只有 C# 和 JavaScript/TypeScript。

2 僅支援目前的使用中檔，因為來賓沒有本機檔案存取權。

3 共用核心偵錯體驗，但不會自動轉送任何已啟動的伺服器。

4 來賓沒有應用程式的本機複本，因此，執行中的應用程式和任何偵錯會話都必須在主機的電腦上啟動。

5 測試回合的輸出會要求任何產生的終端機、輸出窗格和錯誤也會與來賓共用。

6 幾乎所有項目都會直接使用 Node.js fs 模組來建立無法運作的檔案。

已知問題

以下是目前已知的擴充功能問題，可能會防止他們在共同作業會話內容中為來賓工作（以及其因應措施），因此可能會影響其工作流程：

Visual Studio Code

問題 原因 因應措施
使用Node.js fs 模組來偵測/讀取檔案（例如組態檔），或列舉目錄（而您不是語言服務）。 來賓沒有本機檔案存取權。 1.適當地降低用戶體驗 （可能的話）。

2.使用 openTextDocument 和 findFiles 工作區 API 來讀取和列舉檔案。
使用Node.js fs 模組來建立或寫入檔案 與上述相同 N/A 您可以使用 openTextDocument(Uri) API 來建立 untitled 檔案，但無法直接將它儲存至文件系統，位於特定路徑。
視專案配套連結庫或工具而定 與上述相同 1.搭配擴充功能的相依性後援版本

2.支援全域安裝，以在來賓選擇明確安裝時解除封鎖。

3.盡可能遠端狀態/動作，因為主機會有適當的相依性可用。
使用Node.js fs 模組建立目錄 與上述相同 N/A
將功能限制為使用配置 file 的檔。 來賓端的檔案會使用 配置 vsls 。 新增對檔案的支援 vsls （範例）
Uri.file使用方法和/或Uri.fsPath/TextDocument.fileName成員串行化/剖析 URI 與上述相同 請 Uri.parse 改用 和 Url.toString() ，以維護及尊重檔案設定 （例如）
workspace.openTextDocument使用 方法搭配檔案路徑，而不是Uri 與上述相同 Uri提供 實體，而不是來源路徑字串 （範例）
workspace.rootPath使用 屬性來偵測工作區是否存在 屬性workspace.rootPath會在中的workspace第一個 workspaceFolder 上呼叫 Uri.fsPath ，其有上述相同問題 workspace.workspaceFolders請改用 屬性來偵測工作區是否存在，並視需要查看每個 workspaceFolder工作區Uri.scheme，以判斷其是否為本機
註冊語言服務時未指定檔設定（透過 LanguageClient或 languages.register* 方法） 來賓會收到來自其本機延伸模組和主機的語言服務結果，因此，如果兩個參與者已安裝相同的語言服務延伸模組，來賓將會看到特定專案的重複專案（例如自動完成、程式代碼動作） 將語言服務限制為僅限 file 和 untitled 設定 （範例）
在填入DiagnosticCollection檔之前未檢查檔Uri.scheme 與上述相同 只產生Diagnosticsdocuments其 Uri.schemefile === （範例）
從自定義傳回 Tasks 時，不要檢查工作區配置 TaskProvider 來賓會顯示所有遠端和本機工作，因此，如果兩個參與者都安裝了相同的擴充功能，則會顯示重複專案 只針對WorkspaceFolder其 Uri.schemefile === （example） 的 傳回Tasks

另請參閱

有問題嗎？ 請參閱疑難排解或提供意見反應。