转自微软：https://msdn.microsoft.com/zh-cn/mt848633
作者 Julie Lerman | Connect(); 2018 特刊
Visual Studio Live Share 的出现让我激动不已，希望这样的真情流露不会显得自己太尴尬！第一次看到早期预览版的演示时，我就立刻有理由在实时传送视频流会话中使用它。Jeff Fritz 和我在此会话中共同开发一个 .NET Core 项目，我们两人都使用自己的计算机，且相距几乎 400 英里。
实时共享不是屏幕共享会话（即我用来帮助对计算机上的某软件感到困惑的非计算机专业人员那样的）。而是 Jeff 在他的 Windows 计算机上使用 Visual Studio 编写代码，同时我在自己的 MacBook 上使用 Visual Studio Code 编写相同的代码。他所键入、删除或调试的任何内容都会呈现在我的代码中。我对代码所做的任何更改也会呈现在他计算机上的 Visual Studio 中。如果他在 Visual Studio 中打开一个文件，这个文件也会在我计算机上的 Visual Studio Code 中打开。我们仍有自己的光标，可以一起工作，也可以单独工作。
听起来有些不可思议？我也这么认为。因此，我确实进一步研究了一组常见的“假设分析”问题，并深入了解了这一超棒的新工具。让我们来看一看。
内部原理
在你使用 Microsoft 或 GitHub 凭据进行会话身份验证后，Live Share 便会尝试以对等方式与其他开发人员连接，但也会视需要回退到 Azure 中继。与外部参与者协作时，这是通过 Azure 完成的；也就是说，必须有 Internet 连接。若要授予来宾对解决方案的完全访问权限，Live Share 只向其他人传递项目的文件系统结构，而你无需上传任何代码。如果有人打开文件，它就会发送文件内容。若有更改，它便会发送字符差异。调试时，它会发送调试步骤和调试状态。共享测试将在不久的将来推出。Live Share 收集传入的数据，并在 IDE 中显示它。它可以响应打开文件的协作者，并自动在另一个 IDE 中打开相应文件。不过，由于可能想要同时编辑不同的文件，因此可以禁用自动文件切换功能。
协作突破
这种体验比让客户端在 Skype 屏幕共享会话中向我显示代码要好很多倍。我住在 Internet 速度有限的山坡上，Live Share 在有人编辑时仅传输文本文件内容和极少的数据意味着，共享比通过 Internet 传输整个屏幕图像快得多。此外，如果通过 Skype 与其他人协作，我需要不停地问：“能单击这个吗”、“能滚动到那里吗”、“如果更改第 x 行代码后会怎么样…噢，请稍等，可以打开设置并显示行号吗？”。 即使我使用能控制其他人鼠标的工具（如 LogMeIn），也很不方便。延迟问题始终存在，并且在其他人的 IDE 中工作并不总有意思。其他人的设置通常不同。有时，他们的配色方案会导致我看不清楚。或者字体太小。所有这些都会妨碍协作变得顺畅有效。这是我多年来不坐飞机与开发人员和团队协作或指导他们所积累的经验。我敢肯定，对于分布式团队中的任何一位成员，这听起来都太熟悉了。
正因为此，我会对 Live Share 的功能如此激动。无论我是在执行代码评审、帮助某人解决“在我的计算机上有用，但在其他人计算机上没用”的问题，还是在与某人结对编程，Live Share 都是巨大突破。不是只有我有这种反应。浏览第一次发现 Live Share 的开发人员的推文时，可能会觉得 Twitter 上的 #vsliveshare 井号标签非常有趣。
Live Share 可用于各种语言和平台。我甚至还对使用 VB.NET 的旧 .NET 4 WinForms 解决方案使用过它！虽然 VS Code 的语言支持比 Visual Studio 更广泛，但在 Visual Studio 中，可以使用 C#、VB.NET、F#、C++、Python 等。请参阅“语言和平台支持”页 (bit.ly/2Oqjds3)。
调侃也调侃够了，接下来一起来看看如何使用 Live Share。我将在一台计算机上使用多个 Visual Studio 实例进行演示，这样你就可以跟着我一起操作（如果你愿意的话），而不用立刻找到协作者。最好自行操练和探索功能。
激活 Live Share 会话
尽管 Live Share 将是 Visual Studio 2019 的内置功能，但它目前是 Visual Studio Code 和 Visual Studio 2017 的扩展。作为扩展，它仍处于预览阶段。我将重点介绍 Visual Studio 2017 中的体验。
默认情况下，Live Share 与 Visual Studio 登录名相关联，此扩展会在 UI 中的登录信息和虚拟形象旁边添加指示符（见图 1）。 单击 Live Share 按钮，可以激活会话，但前提是已在 Visual Studio 中打开目标解决方案、项目或文件夹。也可以从“文件”菜单启动会话。在你单击后，按钮文本就会从“Live Share”变成“正在共享”。
单击“Live Share”按钮可以激活新的 Live Share 会话
图 1：单击“Live Share”按钮可以激活新的 Live Share 会话
当你首次在 Visual Studio 中激活 Live Share 时，系统会提醒你注意默认是通过本地网络连接进行协作，并提示你允许相关防火墙设置。如果你选择拒绝打开这些端口，它的行为会变成改为通过 Azure 路由所有连接（甚至是同一网络中的连接）。稍后可以根据需要更改此设置。
为什么需要通过本地网络连接进行协作？原来 Live Share 已被同地协作的团队广泛采用。假设能够帮助团队中的某人快速解决问题，而仅对工作流造成小中断。与某人结对编程时，两个人通常共用一个键盘和一个屏幕，自由度可能是个问题。当团队进行 mob 编程时，每个人都在看着从一台计算机投影的屏幕。现在，可以并排而坐（或在大厅两头坐着，或在不同楼层坐着），并仍一起协作，但每个开发人员都能在视自己需要设置的 IDE 中工作，这会实现每个用户的真正参与。是时候在键盘上交换角色时，虽然实际移到“驾驶员”位置的这一步操作有很多优点，但现在可以更为轻松，且没人需要在可能不便的环境中使用不熟悉的计算机。
启动会话后，接下来便会在菜单下方看到黄色栏（如图 2 所示），其中指明邀请链接已复制到剪贴板，你可以与任何来宾共享。这可以很好地提醒，要协作编写谁的代码，谁就需要启动会话。不能像使用屏幕共享时一样切换方向。
启动 Live Share 会话后显示的信息栏
图 2：启动 Live Share 会话后显示的信息栏
单击“更多信息”链接会打开一个窗口，其中显示了一些关于 Live Share 的入门信息。
奇妙的是，最多可以邀请五个人加入会话。不过，这样可能会非常混乱，但可以控制谁能与代码交互，谁只能查看所发生的情况。单独使用链接，可以让协作会话对来宾只读。
邀请链接是可以粘贴到浏览器中的 URL，也是可以直接粘贴到 Visual Studio 中的 URL（在“文件 | 加入协作会话”菜单选项下）。如果是使用浏览器的来宾，便会转到显示邀请创建用户的身份的网页，并看到提示打开“选择应用”Windows 界面的弹出窗口。可以在其中选择 Visual Studio 或 Visual Studio Code，随后选定 IDE 便会打开并设置 Live Share 会话。作为来宾，你会看到帐户旁边有指示符，指明已与“JL”（在此示例中）一起加入会话（见图 3）。通过链接共享的解决方案、项目或文件夹是在解决方案资源管理器中打开。在我的解决方案资源管理器中，我可以看到已中继到我的计算机的代码临时存储在 C:\Users\Julie\AppData\Local\Temp\ 内的文件夹中。请注意，只传递了文件结构和代码文件。我在临时文件夹中找不到任何 .csproj 或 .sln 文件。生成操作不会在临时文件夹中留下任何箱或调试。即使更改默认值并允许来宾触发生成，生成操作也是在主机上执行。这一切都是为了在来宾上显示文件，而不是重新创建解决方案或项目。
Visual Studio 指明已与 JL 一起加入 Live Share 会话
图 3：Visual Studio 指明已与 JL 一起加入 Live Share 会话
在通过邀请链接打开的网页上，还有供来宾将此扩展安装到这两个 IDE 之一的链接（如果尚未安装的话）。我喜欢它简单且可检测，无需随链接发送大量说明。
如前所述，无需使用相同 OS 或 IDE 来启动会话。我的 Windows 计算机上既安装了 Visual Studio 2017，也安装了 VS Code。我将会把 Visual Studio 2017 用作已邀请协作者。请注意，我同时扮演主机和来宾这两种角色。为此，可以在同一台计算机上使用多个 Visual Studio 或 VS Code 实例，这是熟悉 Live Share 的绝佳方式。请注意，暂无适用于 Visual Studio for Mac 的 Live Share 扩展。
连接后，来宾计算机会在 UI 中添加一些闪亮效果，包括内含主机大写首字母的图标（称为“徽章”）。即为图 3 中的蓝色圆圈。（我很快就会解释围绕圆圈一圈的环。） Live Share 按钮指明来宾已加入会话。我的 Visual Studio 主机实例上的 Live Share 按钮内含“正在共享”下拉列表，类似于图 3 中的“已加入”下拉列表。它还会提示我，来宾已加入会话，我可以接受或拒绝此连接。我单击了“确定”，以接受此连接。如果在一台计算机上使用两个 Visual Studio 实例，无法使用两个不同的 Visual Studio 登录标识，因此我在两个实例中都是有蓝色 JL 徽章的 Julie Lerman。
默认情况下，无论主机在解决方案中如何游走，来宾都会跟随主机。因此，如果我在主机实例中打开 program.cs 文件，相应文件也会在来宾 IDE 中打开。不过，如果来宾打开其他文件，相应文件不会在其他任何参与者的 IDE 中自动打开。此行为受控于 Live Share 按钮下拉列表中的操作以及徽章。“已加入”或“正在共享”下拉列表（图 4）都有“焦点参与者”选项。如果此选项已被选择，系统便会通知其他参与者，他们现在将跟随此协作者的焦点。请注意图 3 中围绕蓝色徽章一圈的附加环。这表明，此 IDE 正在跟随另一位协作者。可以单击徽章，以打开和关闭焦点。如果协作从“让我们一起处理同一个文件”变成“噢，请稍等，你能签出其他文件来复制某文本吗？”，这会非常方便。
包含主机专用选项的“正在共享”菜单下拉列表
图 4：包含主机专用选项的“正在共享”菜单下拉列表
但下拉列表和徽章中仅包含会话专用操作。此扩展还在“工具 | 选项”的“Live Share”部分中添加了几十个设置，如图 5 所示。
使用“工具 | 选项”中的设置控制 Live Share 行为
图 5：使用“工具 | 选项”中的设置控制 Live Share 行为
来宾 IDE 有趣的另一面是，如果在解决方案资源管理器中右键单击项目或文件，只会在关联菜单中看到“转到 Git 更改”这一项。 在我的示例中，此项最初处于禁用状态。在解决方案资源管理器中右键单击解决方案会看到一个菜单，其中包含文件或文件夹添加选项，以及设置修改、调试和启动选项。关联菜单受限的原因同样是，解决方案和项目文件不可用。这样一来，Visual Studio 会将它们视为简单文件，而不是 .NET 项目。
与协作者共同编辑
任何拥有默认（相对于只读）访问权限的人都可以编辑文件。主机可以在解决方案资源管理器中添加或重命名文件夹和文件。
默认编辑行为（无论是主机的，还是来宾的）从用于选择代码中文本或位置的鼠标单击开始。如果某参与者移动光标，其他参与者会在自己的文本中看到标记。例如，在图 6 中，来宾 Julie Lerman 发现从第 22 行开始方法尚未实现，并建议重构它。主机 Julie 表示：“放手去做！” 来宾首先会单击相应行的开头，而其他参与者的 IDE 中则会显示标记，以及执行此操作的用户的用户名。用户名会逐渐消失，但标记一直会显示。
当参与者将光标移到此行开头处时显示的标注
图 6：当参与者将光标移到此行开头处时显示的标注
当来宾选择方法的四行代码时，其他用户可以在自己的 IDE 中看到展开后的选定内容，以及她的用户名（见图 7）。
当 Julie Lerman 选择文本时，所有参与者可以看到的内容
图 7：当 Julie Lerman 选择文本时，所有参与者可以看到的内容
如果她点击删除键，相应代码行也会从其他参与者的代码中删除。
如果主机使用的是源代码管理，变更也会作为变更显示在团队资源管理器中。
这实际上就是共同编辑的主要内容。接下来将转为介绍另一项有趣功能，即共同调试。
共同调试
我在前面提到过，Live Share 捕获并传输调试步骤和断点。这是要介绍其实际效果的另一项炫酷功能。
如果一位参与者设置断点，此断点会在所有参与者 IDE 中自动设置。如果主机将默认设置（见图 5）更改为允许来宾调试，来宾就也可以在主机上触发调试。然后，每个 IDE 都会运行调试，并在断点处停止，同时显示现有详细信息。不过，是否查看这些详细信息是每个来宾自己的选择。一位参与者可能会打开错误窗口；另一位参与者可能更愿意将鼠标悬停在断点代码之上，以查看调试信息。
这就产生了能否生成项目或解决方案的问题。我在前面提到过，默认禁止来宾生成。实际上，在共享会话期间，已从来宾 IDE 中删除 Visual Studio“生成”菜单；为了默认确保安全，只有主机才能生成项目或解决方案。在这种情况下，来宾会显示生成输出，但通过仔细检查，我发现输出来自主机；也就是说，生成输出显示主机的文件路径。这是因为，生成操作是在主机上执行的。如果再看一下图 5，将会发现有选项可允许来宾生成项目或解决方案。但如果启用此设置，必须启动新会话，才能在来宾计算机中启用它。调试是相同的。默认情况下，来宾无法触发调试会话，但可以在主机上更改此设置。请注意，来宾无法规避此限制，也无法使用命令行接口 (CLI) 命令来执行生成或调试操作。请注意，项目不在来宾计算机上。稍后，我将介绍如何使用“共享终端”功能来共享主机终端，从而允许用户在主机上查看并运行命令行命令。
调试操作（如单步执行或跳过）也会中继到协作者。当你单步执行代码时，他们会跟着一起做，即使他们已禁用跟随模式（通过单击协作者徽章，以去除围绕徽章一圈的环，如图 3 所示），也不例外。
调试不仅仅只是指单步执行代码。如果处理的是 ASP.NET Core 项目（如网站或 Web API），可以共享主机使用的服务器，这样来宾就能跨网络或 Internet 实际浏览主机的服务器了。起初，我对此感到有些困惑，因为一想到我的开发计算机的服务器可以通过 Internet 访问就有点可怕。但共享是通过安全 SSH 或 SSL 隧道完成。默认情况下（以及可配置的情况下），服务器会在你启动调试 (F5) 或运行 (Shift F5) 时自动共享。若要显式共享服务器，可使用主机的“正在共享”下拉列表中的“管理共享服务器”选项，如图 8 所示。
设置共享服务器
图 8：设置共享服务器
还可以显式共享 TCP 上托管的其他服务器。例如，如果 TCP 上有 SQL Server，可以公开它的端口，并允许协作者连接到此数据库。若要详细了解共享服务器，以及此功能的一些防范措施，请访问 bit.ly/2FlWnlU。
当服务器已共享且应用程序在主机上运行后，来宾可以使用 Live Share 下拉列表来选择“查看共享服务器”选项。这会列出主机已共享的服务器。图 9 展示了一项有趣功能的实际效果：端口 3358 已在我的计算机上使用，因此 Live Share 已登记可用端口 (3407)，以通过我的计算机公开 3358。
公开用于共享服务器的可用端口
图 9：公开用于共享服务器的可用端口
作为来宾，我选择了“用浏览器打开”，起初我觉得出问题了，因为我看到了 404 错误：“找不到 Web 地址 http://localhost:3407/ 对应的网页”。 不过，这是因为我正在运行 Web API，并且需要转到正确的 URL，即“http://localhost:3407/api/values”。 一旦我做了，我的来宾浏览器中便会显示 API 输出。
若要调试控制台应用程序，请注意，VS Code 可以在来宾会话中打开控制台窗口，但 Visual Studio 2017 尚无法这样做。
还可以共享终端！
若要在 Visual Studio 2017 中生成 .NET Core 应用，可能不会太多依赖 .NET CLI 或其他命令行工具。VS Code 用户使用 CLI 的可能性更高，因为他们无法使用 Visual Studio 的所有花哨附加功能。不过，若要在编写、运行或调试应用的上下文中运行终端命令，可能还需要使用共享终端功能，以在参与者之间共享控制台窗口。
主机可以通过“正在共享”下拉列表共享只读或读/写终端。这会在主机和来宾计算机上立即打开终端窗口。请注意，如果你已安装可以在 Visual Studio 2017 中启用集成终端的 Whack Whack Terminal 扩展 (bit.ly/2PuVDzu)，Live Share 会改用此终端。当主机键入内容时，来宾可以在终端窗口中看到每次按键敲击。如果来宾拥有写入访问权限，他们键入的任何内容都会显示在其他参与者的终端上。如果来宾运行“dotnet build”命令（举个例子），便会执行生成操作，尽管与在 Visual Studio 中生成一样，生成操作是在主机计算机上执行的。
安全性高！
我已提到过许多与安全性相关的行为。主机和来宾是使用 Microsoft 或 GitHub 凭据进行验证。默认情况下，会话共享为可编辑，但也有只读邀请链接可共享。当来宾加入会话时，主机会收到通知，并能接受或拒绝此来宾，同时还能随时踢掉来宾。默认情况下，来宾无法触发生成或调试，项目和解决方案文件不在来宾计算机上。
还有主机可控制的其他安全功能。您可以：
通过“身份验证”下的“需要来宾审批”设置（如图 5 所示），延迟来宾连接到共享会话。可以将这看成是 Skype 大厅。
使用 .vsls.json 文件（可以在其中指定哪些文件应受到限制），控制文件访问权限，以及对文件夹或项目的可见性。
在 Active Directory 环境中更严格地控制来宾访问权限
所有这些都是使用 Live Share 在小型或大型企业团队中开展协作时的重要注意事项。若要详细了解这些功能，请参阅“Live Share 的安全功能”文档 (bit.ly/2AMyobo)。
结束会话
主机可以通过“正在共享”下拉列表结束会话，届时所有来宾都会被踢出会话（使用友好通知）。临时文件也会从来宾计算机上清理掉。当然，来宾可以随时离开会话；如果是这样，主机会收到通知。
有趣的是，我的 Internet 连接在会话期间断开（我的路由器有些异常）。Live Share 通过在主机系统中发出通知进行响应，通知指明中继侦听器已脱机，我应该考虑在恢复联机后重新共享。
Live Share 有广阔前景！
Visual Studio Live Share 是一项“突变”功能，面向将 Visual Studio 和 Visual Studio Code 用于各种用例的开发人员。由于分布式团队越来越常见，因此团队成员能够这样协作编写代码显得非同寻常。但优势不仅只是对分布式团队而言，还有其他许多用例，如启导、代码评审、培训、帮助解决问题等。不知有多少次有人问我在编写代码时遇到的奇怪问题，而我的回答是，我真的没法不假思索地回答你，我需要亲自观察整个代码调试。现在，Live Share 让这一切变得非常简单。文档中甚至还有一页 (aka.ms/vsls-usecases) 介绍了所有类型的用例，可启发你的思路。有些我甚至还未曾思考过，如编码访谈。这每次都能打败白板访谈，并能远程完成！
最后，与 Skype 共享屏幕相比，数据传输量最小可以为 Internet 连接速度较慢或不可靠的开发人员带来显著优势。我自己的 Internet 速度就受到限制，因为我住在美国郊区。但这只是小小的不便：通常意味着，我在使用 Skype 进行语音和屏幕共享时，应关闭摄像头。不过，我还启导了尼日利亚拉各斯（令人惊叹的技术中心）以及世界其他地区的一些开发人员好友，这些地区的 Internet 连接存在间歇性，如果我没记错的话，他们使用了手机将 Internet 访问中继到自己的计算机。对我来说，这实际上正中要害：Live Share 不仅普遍提高了开发人员的工作效率，还成为开发社区的巨大突破。