根据国外网友分享：真正令人失望的是，微软会通过插入一个专有扩展来继续锁定 .NET，从而颠覆一个活跃的开源项目。

平台管理者不可接受的滥用权力，以及对社区的背叛。

在 omnisharp/omnisharp-vscode/issues/5276 网友发言，阐述了事情的来龙去脉：

先是微软员工说：

在过去的几个月中，.NET 团队评估了发展 .NET 工具生态系统并将更多功能整合到 VS Code 中的方法。目前，VS Code 中的 C# 体验由 OmniSharp 提供支持。这要感谢Filip Wojcieszyn、David Driscoll、Martin Björkström以及 Jason Imison 的领导，他最初在八年前开始了 OmniSharp 项目。OmniSharp 使用当时可用的 API 和协议将 C# 体验带入 VS Code，从而引起了极大的兴趣。VS Code 已经成熟，今天，语言服务器协议(LSP) 已成为现代开发人员工具相互交流的标准机制。我们相信，将 C# 扩展迁移到 LSP 将帮助我们实现创建可扩展且灵活的工具环境的目标，该环境可以轻松地将新体验集成到 C# for VS Code 中。

随着我们朝着 VS Code 中 C# 体验更加动态的未来迈进，我们打算将扩展切换为完全使用 LSP 进行通信，并计划更新现有的 OmniSharp 组件以也以这种方式进行通信。利用 LSP 将使我们能够为 C# 的 VS Code 扩展带来创新的新功能。这包括提供高级功能，以及在某些情况下提供闭源体验，例如 IntelliCode。我们计划创建一个新的“LSP Tools Host”组件（不是官方名称）)，它将Roslyn和Razor等开源组件与闭源组件集成在一起，提供了更广泛的工具功能。

一旦“LSP 工具主机”完成，这将成为 C# for VS Code 扩展的默认体验。现有用户将能够在现有的开源 OmniSharp 驱动系统或新的“'LSP 工具主机”之间进行选择，后者将提供额外体验的访问权限。“LSP 工具主机”不会开源，但我们计划在此过程中与社区进行交流，以帮助指导我们未来的计划。

我们要再次感谢 OmniSharp 的每个人以及该项目的所有贡献者，感谢他们在帮助将 C# 开发人员体验带入 VS Code 方面所做的出色工作。我们一直与 OmniSharp 团队合作，并将与他们合作以确保此过程顺利进行，并计划与他们以及更广泛的社区合作，以推动 .NET 工具的这一激动人心的新未来。

后续步骤（理想情况下，这些将是可跟踪的问题，这些问题的时间表可能会有所不同）

更新 C# for VS Code 扩展以默认通过 LSP 与 OmniSharp 服务器通信。

将 C# for VS Code 扩展切换为默认使用新的“LSP 工具主机”，并允许用户选择替代语言服务器。

为 VS Code 扩展提供 C# 与这些新的默认值捆绑更多“开箱即用”的功能。

将 C# for VS Code 扩展从 github.com/OmniSharp/omnisharp-vscode 移动到 github.com/dotnet/vscode-csharp 并让 Microsoft 保持最新并发布。此举将使我们能够轻松集成和重用现有的 dotnet 基础设施资产，例如我们共享的构建、测试和发布系统，并将降低总体工程成本。

更新：

感谢热情的反馈。我想澄清反馈中提到的一些我们未能明确的事情。

Razor 和 C# 的 LSP 实现将像今天一样保持开源（Roslyn 和 Razor）。VS Code C# 扩展 (ms-dotnettools.csharp) 本身也将保持开源。今天的开源仍然如此，并且在积极的 OSS 开发中。这确保了 VS Code 之外使用 LSP 的其他人继续有权访问 C#。

这个新的主机组件是开放和封闭源代码功能之间的桥梁，让我们可以同时提供两者。

---

网友指出：

a: 当微软试图通过做出敌视用户的决定来在短期内争夺权力（或从现有市场份额上获得回报）时，这是可悲和短视的。

这似乎是另一个拥抱/扩展/熄灭的例子。现在是可以预见的，但我对此并不高兴！

b: 您能否解释一下为什么这个新工具主机将是闭源的？这似乎与 VS Code 的精神相矛盾。

MS 通过构建开源赢得了开发人员的大量善意，如果改变这一点并重新开始使用旧习惯将是一种耻辱。

c: 这种行为让我为有一个 100% 依赖 .NET 的开源项目感到尴尬。你在微软拥有非常好的技术，不要再用这些落后的商业决策来浪费它了。

d:
不幸的是，为了支持 Visual Studio 的销售，为了支持 Visual Studio 的销售而压制开源似乎是敌对行为。

---

微软补充回应：

感谢您的热情反馈。我想澄清反馈中提到的一些我们未能明确的事情。

Razor 和 C# 的 LSP 实现将像今天一样保持开源（Roslyn 和 Razor）。VS Code C# 扩展 (ms-dotnettools.csharp) 本身也将保持开源。今天的开源仍然如此，并且在积极的 OSS 开发中。这确保了 VS Code 之外使用 LSP 的其他人继续有权访问 C#。

这个新的主机组件是开放和封闭源代码功能之间的桥梁，让我们可以同时提供两者。

----

编者点评：

微软如果想从闭源组件上打主意，我打赌最终会被人民所唾弃。

你一个开源项目，要么你就好好开源。 开源了，你又缩回去。或者说存心不良。

这是闹哪样。

不说Java 在各个领域都老当益壮。如果你让用户选，一个说开源，实际上不开源，还可能因为你用了商业组件，而被微软起诉，赔钱。 另外一个是完全免费，无需担心，随便使用，没有隐患的Java。

怎么选？很难选是不是？

我会选Java。

除非.net真真正正的从源头上，解决开源的问题，不要夹带私货。这样才可能有长足的进步。

如果微软一直自我消耗，把有限的精力，放到往开源项目里面下毒。

我觉得发展堪忧，微软能把一个组件闭源，就可以弄一万个组件闭源。。一个全部，或者大多数都是商业闭源的所谓开源的.net平台，那还能叫开源的.net吗？

平台就是平台，开源就是开源，商业产品是商业产品。

不要夹带私货，不要混为一谈。

我一直呼吁，如果.net真的要能够获得长足的进步，应该把.net基金会控制权，完全交给开源社区，比如linux基金会，apache基金会，或者其他任何一个第三方独立的基金会，而不是一个隶属于微软的傀儡组织。

微软甚至不用社区会议决定，就可以私自做决定，把组件开源、闭源，向里面下毒。