Linux 发行版的黄金标准是使用作为发行版存档一部分的编译器和工具链构建开源代码 。 这适用于 .NET 运行时（用 C++ 编写） ， 但不适用于任何用 C# 编写的代码 。 对于 C# 代码 ， 我们使用两遍构建机制来满足发行版要求 。 这有点复杂 ， 但了解流程很重要 。
Red Hat 使用 .NET SDK (#1) 的 Microsoft 二进制构建来构建 .NET SDK 源代码 ， 以生成 SDK (#2) 的纯开源二进制构建 。 之后 ， 使用这个新版本的 SDK (#2) 再次构建相同的 SDK 源代码 ， 以生成可证明的开源 SDK (#3) 。 .NET SDK (#3) 的最终二进制版本随后可供 RHEL 用户使用 。 之后 ， Red Hat 可以使用相同的 SDK (#3) 来构建新的 .NET 版本 ， 而不再需要使用 Microsoft SDK 来构建每月更新 。
这个过程可能令人惊讶和困惑 。 开源发行版需要通过开源工具构建 。 此模式确保不需要 Microsoft 构建的 SDK ， 无论是有意还是无意 。 作为开发者平台 ， 包含在发行版中的门槛比仅使用兼容许可证的门槛更高 。 源代码构建项目使 .NET 能够满足该标准 。
源代码构建的可交付成果是源代码压缩包 。 源 tarball 包含 SDK 的所有源（对于给定版本） 。 从那里 ， 红帽（或其他组织）可以构建自己的 SDK 版本 。 Red Hat 政策要求使用内置源工具链来生成二进制 tar 球 ， 这就是他们使用两遍方法的原因 。 但是源代码构建本身不需要这种两遍方法 。
在 Linux 生态系统中 ， 给定组件同时拥有源和二进制包或 tarball 是很常见的 。 我们已经有了可用的二进制 tarball ， 现在也有了源 tarball 。 这使得 .NET 与标准组件模式相匹配 。
.NET 6 的重大改进是源 tarball 现在是我们构建的产品 。 它过去需要大量的人工来制作 ， 这也导致将源 tarball 交付给 Red Hat 的延迟很长 。 双方都对此不满意 。
在这个项目上 ， 我们与红帽密切合作五年多 。 它的成功在很大程度上要归功于我们有幸与之共事的优秀红帽工程师的努力 。 其他发行版和组织已经并将从他们的努力中受益 。
附带说明一下 ， 源代码构建是朝着可重现构建迈出的一大步 ， 我们也坚信这一点 。 .NET SDK 和 C# 编译器具有重要的可重现构建功能 。
库 API
除了已经涵盖的 API 之外 ， 还添加了以下 API 。
▌WebSocket 压缩
压缩对于通过网络传输的任何数据都很重要 。 WebSockets 现在启用压缩 。 我们使用了WebSockets 的扩展permessage-deflate实现 ， RFC 7692 。 它允许使用该DEFLATE算法压缩 WebSockets 消息负载 。 此功能是 GitHub 上 Networking 的主要用户请求之一 。
与加密一起使用的压缩可能会导致攻击 ， 例如CRIME和BREACH 。 这意味着不能在单个压缩上下文中将秘密与用户生成的数据一起发送 ， 否则可以提取该秘密 。 为了让用户注意到这些影响并帮助他们权衡风险 ， 我们将其中一个关键 API 命名为DangerousDeflateOptions 。 我们还添加了关闭特定消息压缩的功能 ， 因此如果用户想要发送秘密 ， 他们可以在不压缩的情况下安全地执行此操作 。
禁用压缩时 WebSocket的内存占用减少了约 27% 。
从客户端启用压缩很容易 ， 如下例所示 。 但是 ， 请记住 ， 服务器可以协商设置 ， 例如请求更小的窗口或完全拒绝压缩 。

var cws = new ClientWebSocket;cws.Options.DangerousDeflateOptions = new WebSocketDeflateOptions{ClientMaxWindowBits = 10,ServerMaxWindowBits = 10};还添加了对 ASP.NET Core 的 WebSocket 压缩支持 。
归功于伊万兹拉塔诺夫 。
▌Socks 代理支持
SOCKS是一种代理服务器实现 ， 可以处理任何 TCP 或 UDP 流量 ， 使其成为一个非常通用的系统 。 这是一个长期存在的社区请求 ， 已添加到 .NET 6中 。