生态系统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

即将推出。

请参阅

遇到问题？ 请参阅疑难解答或提供反馈。