AWS大力支持.NET 开源项目，和Azure抢.NET 客户

出品 | OSC开源社区（ID：oschina2013)

在 2022 re:Invent 会议上， AWS 软件开发经理 Saikat Banerjee 锐评道：” 我们发现 .NET 开源项目资金严重不足，仍可称之为第三方开源”。随即表示 AWS 过去非常重视 .net 生态，未来也将继续大力支持 .NET 的开源发展。

.NET 开源资金不足的说法令人吃惊，微软成立了 .NET 基金会，该基金会的介绍是 “一个独立的非营利组织，旨在支持一个创新的、商业友好的开源生态系统 .NET 平台。” ，而 AWS 是该基金会仅有的 10 家企业赞助商之一。

另一方面，微软的 .NET 团队固然投入了大量精力，但在技术层面上，.NET 开源之后的跨平台进程包含大量外部贡献者的努力。比如 AWS 对 .NET 的开源工作非常上心，不仅给 .NET 基金会捐款支持、对社区中的出色的 .NET 项目进行现金和积分奖励，还积极参与 .NET 跨平台的代码开发工作，努力致力于 .NET 去 Windows / 跨平台化。

根据 Banerjee 的说法，AWS 正试图 “改进 WCF（Windows 通讯开发平台），不让它保留原有的局限性”。这项工作包括对 HTTP 绑定的联合身份支持，以及扩展 WFC 消息队列支持，支持除了 Microsoft 消息队列 (MSMQ) 以外的其他消息代理 ，例如 RabbitMQ 和 Amazon SQS。

另一个关键领域是 Active Directory (AD)，在 Windows AD 中，组托管服务帐户 (gMSA) 通常用作应用程序服务的帐户。AWS 将该组件移植到了 Linux ，开发了一个名为 credentials fetcher 的组件，这是一个位于 Linux 实例上的守护进程，允许在 Linux 容器中使用 gMSA。

此外，使用 .NET 启动 Lambdas 时一直存在冷启动问题。函数运行时都需要加载 .NET 运行时，且 JIT 编译器每次都会将 .NET 中间代码编译为本机代码，这也需要很长时间。.NET 7 版本中的解决方案是本机 AOT 编译， 而 AWS 开发了适用于 .NET 的 Lambda tools ，可将本机 AOT 编译添加到 Lambda 函数中。

AWS 为啥对 .NET 跨平台工作这么上心？这就要追溯到 .NET Core 的前身 .NET Framework ，.NET Framework 出自 Windows 平台，导致调用 COM 或其他本机 Windows API 的 .NET Core 应用程序无法在 Linux 上运行。另一方面， .NET Framework 的某些部分（如 ASP.NET Web Forms 和 WCF 的大部分内容）不属于 .NET Core，使得大多数 .NET 应用程序更适合 Windows 或 Azure 云环境，移植到其他云上相当困难。

大厂当然不会为爱发电搞开源， .NET 是 AWS 应用程序开发中仅次于 Python 和 Java 的第三大受欢迎的平台，AWS 对.NET 开源工作的投资大多是为了让 .NET 摆脱对 Windows 的依赖，更易于使用其 Linux VM 和云原生技术， 以此摆脱 Windows 和 SQL Server 的许可，并获取更多云服务客户。当然，同样的优化当然也适用于微软的 Azure 和其他云环境，你好我好大家好，亦不失为一桩美事。

另，与其说 .NET 开源的 “资金” 不足，不如说 “资源不足 “。微软内部对 .NET 开源的意见恐怕并不统一，对开源业务倾斜的资源也一直在博弈。比如去年微软在即将发布的 .NET 6 中悄悄删除热重载的功能代码，宣称仅在 Visual Studio 中支持该功能，，强制用户改用昂贵的 Visual Studio 2022  。该举动随即引起微软内部 .NET 开发者和外部 .NET 社区的强烈反对和抨击，随后微软高层道歉，并在 .NET 6 中恢复了热重载功能。