微软开发人员呼吁管理处理 .Net Hot Reload 问题

开源社区的成员最近对微软感到愤怒，因为微软显然有意从开源 .Net 6 软件开发平台（由微软管理）中删除了一项功能，以便专业开发人员转而使用 Visual Studio 2022，微软相当昂贵但非常昂贵。强大的IDE。

事实证明，微软内部的开发人员同样愤怒，微软改变他们的决定并没有安抚他们，许多人担心下一次微软将其短期财务利益放在他们与开源社区的接触上。

这导致发布了一封致微软管理层的匿名信，其中作者直接指责该公司为了保护管理层而撒谎。

他们指出，微软故意在 .Net 6 开发人员可以发表评论之前通过匆忙 PR 来隐藏 Hot Reload 的删除，并且微软的借口他们不能专注于 .Net 6 和 VS 2022 的 Hot Reload 当没有表明工作不能令人满意地完成。

他们表示担心，尽管开源工具在微软内部非常流行，但微软将进一步努力削弱 .Net 6 以推动 VS 2022。

作者要求对 Hot Reload 是如何被拉出的以及微软管理层的变化进行透明的调查，这样就不能再做出这样轻率的决定。

尽管有些刺耳的语气让很多人相信这封信不是真的，但一些微软 MVP 已经站出来确认这封信确实是由微软 DivDev 部门的一名员工写的。

完整阅读以下信件：

致 Microsoft 开发人员部门领导，

我们这些在 Microsoft 开发人员部门 (DevDiv) 工作的人想回应最近围绕 dotnet 6 的“dotnet watch”功能的拉动和恢复引发的争议。虽然我们很感激冷静的头脑占上风和“dotnet watch”被保存下来，我们不相信这不会再次发生？恰恰相反。

为了说明这一点，我们将查看 Scott Hunter 最近的博客文章 (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/)。根据我们对情况和开发人员部门运作方式的了解，斯科特写的几乎没有什么是真实的，并且与发生的事情相矛盾。需要明确的是，这不是对 Scott Hunter 的攻击。相反，它显示了其他人愿意在多大程度上保护管理层。

“作为一个团队，我们致力于让 .NET 成为一个开放平台，并在开放的环境中进行我们的开发。我们决定从一开始就默认采用开放姿态来开发热重载功能这一事实证明了这一点。”

关于拉取请求的任何内容都没有打开。我们在博客文章 (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) 中提到了它，并且不透明地匆忙 PR 以避免注释。当这显然相反时，我们怎么能说我们是透明的呢？就好像我们所有人都知道这是错误的，但无论如何都必须接受。

“绝大多数 .NET 开发人员都在使用 Visual Studio，我们希望确保 VS 为 .NET 6 提供最佳体验。”

即使这是真的，这是否意味着我们不关心非 Visual Studio 用户？如何在开发的这么晚才使用此功能，让 Visual Studio 拥有最佳的热重载体验？这是对那些并不总是使用 Visual Studio 进行 dotnet 开发的人的侮辱，它说我们不了解我们的客户，甚至不了解使用我们构建的产品的员工。

我们使用 CLI，我们使用 VS Code。别再假装了。

“我们在执行该计划时犯了一个错误。在我们努力确定范围时，我们无意中删除了源代码，而不是仅仅没有调用该代码路径。”

需要明确的是，将这个“错误”归咎于工程师是懦弱的。问题在于删除该功能，而不是他们如何执行它。我们是说如果只是“关闭它”而不是删除它，我们就不会恢复更改吗？这段代码会被积极处理还是任其腐烂？

“由于 .NET 6 版本和 Visual Studio 2022 的跑道越来越短，我们选择首先专注于将 Hot Reload 引入 VS2022。”

为了表明“质量控制”不是“dotnet watch”的情况，我们将它与我们延迟的另一个产品进行比较：MAUI。

MAUI 处于粗糙状态。RC1 很清楚，到 dotnet 6 发布时，质量还不够高；有太多的事情要解决，却没有足够的时间去做。MAUI 团队及其合作伙伴将这些问题提交给领导层，从而将产品推回到明年初。

过去和现在都没有迹象表明“dotnet watch”在同一个地方。浏览 GitHub 问题和 dotnet 团队的积压工作都没有表明质量不存在的任何担忧。相反，它做得很好。如果确实存在质量问题，而不是在发货前三周，这些问题会在我们的发布周期中提早提出。

“与许多公司一样，我们正在学习平衡 OSS 社区的需求和成为 .NET 的企业赞助商。”

如果我们在字里行间阅读，这个陈述是正确的。我们与放入 dotnet、Visual Studio 和 Visual Studio Code 的内容相冲突。将热重载作为 Visual Studio 的“附加值”可以让那些锁定在付费产品中，并减少跳转到 VS Code 的理由。冷酷而算计，这完全有道理，也绝对是无稽之谈。

如果为 Visual Studio 进行 Hot Reload 的团队将“dotnet watch”集成到他们的产品中会怎样？如果领导层在正式发布前几周取消这些功能会怎样？这将如何以任何方式改进 Visual Studio？我们是否会继续从 CLI 中删除部分，因为我们担心会失去 Visual Studio 的收入？

我们构建最好的 Visual Studio 的方式是拥有地球上最好的运行时。当 Visual Studio 团队为 dotnet 的基础添加功能时，我们有一个一致的基础供每个人工作和贡献。我们可以通过在运行时协作来构建最好的 IDE，而不是让我们的开源产品变得更糟。

下一步是什么？我们要让 Omnisharp 成为一个闭源产品吗？这样我们就可以确保它不会获得剥夺 Visual Studio“价值”的新功能？这样我们就不会向 Rider 提供功能？这对我们有什么帮助？领导层的这些决定确保 Visual Studio 永远是市场上其他所有产品的二流产品。像这样的举动不仅伤害了我们的客户，还伤害了我们内部构建产品的方式。他们不仅通过“OSS 社区”伤害了我们，还伤害了开发人员部门和 Microsoft 的每个人。

如果我们想对此真正透明，我们应该进行以下更改以使其正确：

我们需要一个完整的时间表，公开发布，说明这是如何发生的以及直接负责如何导致这种情况的人。
我们永远不应该再匆忙通过 PR。从一开始就很明显，删除代码是错误的行为，如果我们真的想要社区的反馈，我们必须愿意倾听而不是之后。
如果这些决定是由领导层单方面做出的，我们需要防止这种情况再次发生。VS 的“需求”与 dotnet 的“需求”之间存在明显的利益冲突。需要进行制衡，以防止任何人，无论他们有多高，在没有来自部门内外的真实反馈的情况下做出这样的决定。

我们在此的目标不是侮辱可能做出此决定的领导层中的任何特定人员。相反，它是为了解决核心问题：没有人应该有如此大的力量来影响像 dotnet 这样接近于直接发布的产品。任何领导开发部门的人都可以做同样的行为，我们需要防止这种行为。制定明确的指导方针来保护这些产品，这些产品构成了 Visual Studio 一切的基础，不仅将使我们成为一流的开源软件管理员，而且还可以帮助我们构建最好的 IDE。