生态系統ftp伺服器,擴充和生态系統支援的 Visual Studio 實時共享 - Visual Studio Live Share | Microsoft Docs...

擴充和生态系統支援

04/25/2018

本文内容

Visual Studio 實時共享的主要目标之一是使開發人員能夠從其最喜歡的互相配合，并高度自定義工具。 這樣一來，即席互動可以發生的頻率，同時保持以可視方式熟悉和人機工程學，無論什麼您将有助于使用。 若要實作此目的，是關鍵協作會話中的參與方都能繼續使用支援的任何擴充其個人首選項和工作流(例如顔色/圖示主題、 鍵綁定和編輯器工作效率增強器)。

此外，要加入協作會話為即時盡可能，同時保持高的工作效率，Visual Studio 實時共享的目标是能夠來賓自動利用其主機已共享的特定于項目的工具。 這樣一來，可以隻需單擊一個連結，啟動所選，工具并開始進行協作，而無需任何額外的設定。 若要實作此目的，該擴充，哪些電源核心編輯、 生成和調試工作流、 在以透明方式"遠端"從主機到來賓作業系統，以便諸如自動完成功能，請轉到定義和調試"正常工作"。

本文檔介紹目前已知的狀态為 vast 擴充生态系統，以及前面提到的目标"記分卡"。 如果你遇到的擴充，不符合此條件，是你個人的工作流的關鍵，然後請告訴我們 ！

特定于使用者的擴充

支援特定于使用者的自定義項的擴充插件必須都可以為主機，并應都可以為所有來賓。 如果擴充不正常的主機的将是一個回歸，并可能是 Visual Studio 實時共享中的 bug (，請提出問題當您看到一個 ！)。 如果擴充不會像預期的來賓，則可能需要擴充本身中的更改，并且我們将使用位址/改進這些方案的生态系統。

Visual Studio Code

1 除非使用者已熟悉代碼段，它們不指望它可用，是以，使它們共享并不一定意義。

2 這些擴充類别如此不同，就無法說它們的工作原理。但是，從理論上講，它們應，并且，我們将跟蹤的鍵能夠 / 無法。

3 這些擴充類别可能受益于協作體驗，是以我們需要知道這些的最終使用者回報 ！

4 這些更新要求來賓在已安裝的運作時工具 (例如 Node.js)，并運作通過本地運作代碼。

5 這些處理通過連接配接到某種類型的伺服器，可以使用任一集中式伺服器、 來賓作業系統已共享的伺服器。

Visual Studio

即将推出。

特定于項目的擴充

主機安裝擴充，它們支援核心編輯、 生成和調試應用程式和特定于語言/平台/庫/SDK，應可自動向來賓，而無需安裝任何内容。 這樣一來，主機可以設定其環境來支援高效開發的一個項目，并允許其來賓可立即将它們聯接起來，而無需其他系統必備元件。 因為主觀或個人以任何方式，不是特定于項目的擴充，它們可以明确地共享從主機到來賓而不會影響任何人的熟悉的環境。

此外，為了支援特定于項目的擴充已安裝來賓，但主機不會理想情況下，它們将提供降級的、 尚未功能體驗 (例如擷取單個檔案 intellisense，能夠設定文檔格式)。

1 目前僅C#和 JavaScript/TypeScript，即将推出的更多支援。

2 将僅支援目前的活動文檔，因為來賓不具有本地檔案通路權限。

3 共享的核心調試體驗，但是，不會自動轉發任何啟動的伺服器。

4 來賓沒有應用程式中的本地副本，是以，正在運作的應用和任何調試會話需在主機的計算機上啟動。

5 測試運作的輸出需要與來賓也共享任何生成終端中，輸出窗格和錯誤。

6 幾乎所有這些将使用 Node.jsfs子產品直接建立檔案，不會起作用。

Visual Studio

即将推出。

已知問題

目前已知的擴充問題，無法阻止這些來賓 (以及它們的解決方法)，協作會話的上下文中工作，是以，可能會影響其工作流如下：

Visual Studio Code

問題

原因

解決方法

使用 Node.jsfs子產品來檢測/讀取檔案 (如配置檔案) 或枚舉目錄 (和不是語言服務)。

來賓沒有本地檔案通路權限。

1.妥善降級使用者體驗 (如果可能)。

2.使用openTextDocument和findFiles工作區 Api 來讀取和枚舉的檔案。

使用 Node.jsfs子產品來建立或寫入檔案

與上面相同

N/A可以使用openTextDocument(Uri)API 來建立untitled檔案，但您不能将其儲存到檔案系統中，在特定路徑直接。

具體取決于項目捆綁庫或工具

與上面相同

1.捆綁包回退的擴充對象的依賴項版本

2.支援全局安裝，若要取消阻止來賓，如果使用者選擇顯式安裝它。

3.如果可能，因為主機都具有正确的依賴項可用狀态/操作遠端連接配接。

使用 Node.jsfs子產品來建立一個目錄

與上面相同

N/A

限制對功能記錄了使用file方案。

在訪客端使用的檔案vsls方案。

添加對的支援vsls文檔 (示例)

使用Uri.file方法和/或Uri.fsPath / TextDocument.fileName要序列化/分析 Uri 的成員

與上面相同

使用Uri.parse并Url.toString()相反，其維護并尊重檔案方案 (示例)

使用workspace.openTextDocument方法而不是檔案路徑 Uri

與上面相同

提供Uri執行個體而不是原始檔案路徑字元串 (示例)

使用workspace.rootPath屬性的工作區狀态進行檢測

workspace.rootPath屬性調用Uri.fsPath第一次workspaceFolder中workspace，其中具有前面所述相同的問題

使用workspace.workspaceFolders相反，檢測是否存在工作區和必要時，我們了解每項的屬性workspaceFolder的Uri.scheme以确定它是否本地

注冊語言服務時未指定文檔方案 (無論是通過LanguageClient，或languages.register*方法)

來賓接收語言服務結果從其本地擴充和主機，并是以，如果這兩個參與方具有同一語言服務擴充插件，來賓将看到的某些方面 (例如自動完成、 代碼的重複項操作)

将語言服務限制為僅file并untitled方案 (示例)

不能檢查文檔的Uri.scheme之前填充DiagnosticCollection它

與上面相同

僅生成Diagnostics有關documents其Uri.scheme === file (示例)

傳回時不檢查工作區方案Tasks從自定義 TaskProvider

來賓顯示遠端和本地的所有任務，而如果這兩個參與方具有同一擴充插件安裝，是以，就會都顯示重複項

僅傳回Tasks有關WorkspaceFolders 其Uri.scheme === file (示例)

Visual Studio

即将推出。

請參閱

遇到問題？ 請參閱疑難解答或提供回報。