官宣.NET 8 RC1的发布

本篇翻译于Leslie Richardson的文章 Announcing .NET 8 RC1。

.NET 8 RC1 现已推出。这是我们两个候选版本中的第一个。此版本包括适用于 Android 和 WASM 的新 AOT 模式、System.Text.Json 改进以及对容器的 Azure Managed Identity支持。如果您还没有开始学习和测试 .NET 8，那么现在正是好时机。

.NET Conf 2023的日期已公布！请加入我们，一起庆祝2023 年 11 月 14 日至 16 日举行的 .NET 8 发布会！

请下载适用于 Linux、macOS 和 Windows 的.NET 8 RC1 。

• 安装程序和二进制文件
• 容器镜像
• 发行说明
• 重大更改
• 已知的问题
• GitHub 问题跟踪器

您还可以查看几篇令人兴奋的帖子：

• .NET 8 RC1 中的NET Core 更新
• .NET 8 RC1 中的 .NET MAUI 更新
• Visual Studio 2022 17.8 Preview 2
• .NET 8 RC1 中的Entity Framework更新
• .NET 8 的新增功能描述了 .NET 8 中的所有新功能。如果想要更全面的了解这个平台，请阅读为什么选择 .NET？。

System.Text.Json 改进

IAsyncEnumerable 的 System.Net.Http.Json 扩展

https://github.com/dotnet/runtime/pull/89258

RC1 中包含了 IAsyncEnumerable 流式反序列化扩展方法：

const string RequestUri = "https://api.contoso.com/books";
using var client = new HttpClient();
IAsyncEnumerable<Book> books = client.GetFromJsonAsAsyncEnumerable<Book>(RequestUri);

await foreach (Book book in books)
{
    Console.WriteLine($"Read book '{book.title}'");
}

public record Book(int id, string title, string author, int publishedYear);

感谢@IEvangelist对此（IAsyncEnumerable 的 System.Net.Http.Json 扩展）提供的实现方法。

JsonContent.Create重载支持JsonTypeInfo

https://github.com/dotnet/runtime/pull/89614

现在可以使用修剪安全/源生成的合约创建 JsonContent 实例：

var book = new Book(id: 42, "Title", "Author", publishedYear: 2023);
HttpContent content = JsonContent.Create(book, MyContext.Default.Book);

public record Book(int id, string title, string author, int publishedYear);

[JsonSerializable(typeof(Book))]
public partial class MyContext : JsonSerializerContext 
{ }

感谢@brantburnett 对此（JsonContent.Create重载接受JsonTypeInfo）提供的实现方法。

JsonNode.ParseAsync APIs

https://github.com/dotnet/runtime/pull/90006

添加对从流中解析JsonNode实例的支持：

using var stream = File.OpenRead("myFile.json");
JsonNode node = await JsonNode.ParseAsync(stream);

感谢@DoctorKrolic 对此（JsonNode.ParseAsync APIs）提供的实现方法。

JsonSerializerOptions.MakeReadOnly(bool populateMissingResolver)

https://github.com/dotnet/runtime/pull/90013

现有的无参数 JsonSerializerOptions.MakeReadOnly() 方法是基于修剪安全而设计的，因此在options实例没有配置解析器的情况下将抛出异常。

调用新的重载

options.MakeReadOnly(populateMissingResolver: true);

如果缺少反射解析器，将使用默认反射解析器填充options实例。 这模拟了接受 JsonSerializerOptions 的 JsonSerializer 方法所采用的初始化逻辑。 该行为的副作用是新重载被标记为 RequiresUnreferenceCode/RequiresDynamicCode，因此不适合Native AOT 应用程序。

Android 上的 AndroidStripILAfterAOT 模式

https://github.com/xamarin/xamarin-android/pull/8172

我们尝试为开箱即用的 .NET 和 .NET MAUI 应用程序选择最佳的默认配置。具体来说，在 .NET 6 及更高版本中，当这些应用程序在Release模式下构建时，默认情况下使用提前预编译的 (AOT)编译模式。 AOT编译在启动时间和运行时性能方面带来了更快的性能，但会以应用程序大小增加为代价 。 提前预编译只AOT编译应用程序的启动路径的一部分 ，从而缩短了启动时间，而应用程序尺寸只增加了很小的一部分。新的 AndroidStripILAfterAOT 设置会删除经过 AOT 编译的未使用的 IL，从而将 dotnet 模板应用程序的 apk 大小至少减小 0 – 3.5%。

何时考虑使用AndroidStripILAfterAOT：

如果您更关心 Android 应用程序的性能，而不是应用程序的大小，那么 AOT 编译所有代码是实现最佳启动和运行时性能的好方法。 $(AndroidStripILAfterAOT) 进一步删除了未使用的 IL，使 AOT 编译带来的应用程序大小的增加更加合理。 删除的 IL 也将不再存在，从而使对应用程序的 .NET 代码进行逆向工程变得更加困难（但并非不可能）。

如何使用AndroidStripILAfterAOT：

请为您的 Android 应用程序设置以下 MsBuild 属性：

<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
</PropertyGroup>

默认情况下，将 AndroidStripILAfterAOT 设置为 true 将覆盖默认 AndroidEnableProfiledAot设置，从而允许删除所有可修剪的 AOT 方法。 通过显式设置，可以将提前预编译 和 IL 剥离一起使用：

<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
  <AndroidStripILAfterAOT>true</AndroidStripILAfterAOT>
  <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
</PropertyGroup>

dotnet  创建新的Android应用程序的 .apk 大小结果：

$(AndroidStripILAfterAOT)	$(AndroidEnableProfiledAot)	.apk size
true	true	7.7MB
false	true	7.7MB
true	false	8.1MB
false	false	8.4MB

请注意，$(AndroidStripILAfterAOT)=false 和 $(AndroidEnableProfiledAot)=true 是默认的 Release 配置环境，生成的apk大小为 7.7MB。

限制

并非所有经过 AOT 编译的方法都可以删除。在运行时，有多种场景需要我们从 AOT 切换到 JIT 才能产生正确的结果。尽管如此，我们将在即将发布的 .NET 9 版本中不断努力缩小这些差距。

最后说明

我们诚邀大家尝试这项新功能，并提交任何发现的问题，以帮助我们进一步改善用户体验。问题可以直接提交到dotnet/runtime 存储库。

配置绑定生成器的重大更改

配置绑定生成器已切换为使用编译器拦截器预览功能来发出绑定逻辑 –

https://github.com/dotnet/runtime/pull/90835。

在非 Web SDK 场景中（即需要 Microsoft.Extensions.Configuration.Binder 包引用进行绑定的应用程序，例如控制台应用程序），现在需要以下附加的 MSBuild 属性来启用生成器：

<PropertyGroup>
  <EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
+ <Features>$(Features);InterceptorsPreview</Features>
</PropertyGroup>

这是暂时的。在 RC-2 中，启用生成器将改回仅需要一个手势就可以进行切换。编译器接收器功能将以可靠的方式隐式启用。

<PropertyGroup>
  <EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
- <Features>$(Features);InterceptorsPreview</Features>
</PropertyGroup>

容器切换到非预览标签模式

问题：https://github.com/dotnet/dotnet-docker/issues/4772

PR：https://github.com/dotnet/dotnet-docker/pull/4817

为了准备 .NET 8 的 正式 版本，.NET 容器映像已切换到 RC 1 的新标签模式，并从标签名称中删除“preview”。

在之前的 .NET 8 的预览版本中，浮动标签以 8.0-preview 和 8.0-preview-<OS> 的名称发布。 从 RC 1 版本开始，这些将不再被维护。 相反，您应该将标签引用迁移到 8.0 或 8.0-<OS>。 进行此更改将允许在 .NET 8 正式 版本上实现无缝过渡，因为这些将成为在 .NET 8 的整个生命周期中维护的永久标签。

在非 Windows 上使用 Win32 资源跨平台构建 Windows 应用程序

问题：https://github.com/dotnet/runtime/issues/3828 PR:

https://github.com/dotnet/runtime/pull/89303

非常感谢@anatawa12做出的的巨大贡献！

在非 Windows 平台上构建面向 Windows 的应用程序时，生成的可执行文件现在会使用任何指定的 Win32 资源进行更新，例如应用程序图标、清单、版本信息。

在以前，应用程序必须在 Windows 上构建才能拥有此类资源。修复跨平台支持一直是一个呼声很大的请求，因为它是影响基础设施复杂性和资源使用的一个重大痛点。

SDK：Container发布现在支持 Azure Managed Identity

• 使用Managed Identity时 Azure Container Registry身份验证失败

SDK Container发布功能是一种将 .NET 应用程序打包到容器中并将其推送到容器注册表（例如 Docker Hub、Azure Container Registry或其他流行注册表）的简单方法。 推送到这些远程注册表通常需要身份验证，这通常由 docker login 命令处理。有些注册表（例如 Azure Container Registry）不使用标准用户名/密码设置，而是依赖于 OAuth 令牌交换。 SDK Container发布工具不知道如何处理此令牌交换，所以在 Azure Container Registry上使用Managed Identity（或使用任何其他使用身份令牌交换的注册表）的用户在推送其容器时会遇到身份验证错误。 在 .NET 8.0.100 RC1 中，我们很高兴地宣布，我们现在支持 OAuth 令牌交换身份验证方法，因此 ACR 和使用它的所有其他注册表现在都可以正常工作。 典型的发布流程如下所示：

> az acr login -n <your registry name>
> dotnet publish -r linux-x64 -p PublishProfile=DefaultContainer

没有比这更简单的了！您可以在我们的文档中了解有关注册表身份验证的更多信息，并且还可以了解如何开始容器化您的应用程序。

WASM 上的 WasmStripILAfterAOT 模式

https://github.com/dotnet/runtime/pull/88926

Blazor WebAssembly 和 WASM Browser支持提前 (AOT) 编译，您可以将 .NET 代码直接编译到 WebAssembly 中。AOT 编译以更大的应用程序体积为代价，提高了运行时性能。根据我们在上述 github 问题中提到的测试，这种新的剥离模式将 _framework 文件夹的大小减少了 1.7% – 4.2%。

何时考虑使用WasmStripILAfterAOT：

每当您启用 AOT 编译时，此功能都是理想的选择，因此请在较小的应用程序中尝试一下！

如何使用WasmStripILAfterAOT:

请为您的Blazor WebAssembly或WASM Browser应用程序设置以下MsBuild属性：

<PropertyGroup>
  <RunAOTCompilation>true</RunAOTCompilation>
  <WasmStripILAfterAOT>true</WasmStripILAfterAOT>
</PropertyGroup>

它将删除大多数已编译方法的 IL 代码，包括库中的方法和应用程序开发人员编写的方法。

限制

并非所有编译方法都是可修剪的。在运行时，有很多场景我们必须从 AOT 切换到解释器才能产生正确的结果。尽管如此，我们将会继续努力在即将发布的 .NET9 版本中缩小这个差距。

最后说明

我们诚邀大家尝试这项新功能，并提交任何发现的问题，以帮助我们进一步改善用户体验。问题可以直接提交到dotnet/runtime 存储库。

RDP 中的 WPF 硬件加速

https://github.com/dotnet/wpf/pull/7684

在过去，所有远程访问的WPF应用程序都必须使用软件渲染，即使系统具有硬件渲染功能。我们添加了一个新选项，允许应用程序开发人员能够利用 AppContext 开关选择加入 RDP 硬件加速。

硬件加速是指使用计算机的图形处理单元（GPU）来加速应用程序中图形和视觉效果的渲染。这可以提高性能并提供更无缝、响应更快的图形。相比之下，软件渲染仅依靠计算机的中央处理单元 (CPU) 来渲染图形，速度较慢且效率较低。

如何在 RDP 中为 WPF 应用程序启用硬件加速？

我们提供在 RDP 中启用硬件加速的两种方法：

1. 通过在*.csproj文件中添加RuntimeHostConfigurationOption，如下所示：

<ItemGroup>
      <RuntimeHostConfigurationOption Include="Switch.System.Windows.Media.EnableHardwareAccelerationInRdp" Value="true" />
</ItemGroup>

2. 通过在*.runtimeconfig.json文件中添加configProperty，如下所示：

“configProperties”: {      “Switch.System.Windows.Media.EnableHardwareAccelerationInRdp”: true    }

最后说明

我们诚邀大家尝试这项新功能，并提交发现的任何问题，以帮助我们进一步改善用户体验。问题可以直接提交到dotnet/wpf 存储库。

社区贡献者

本月的社区贡献者是 Jakub Majocha。以下是他自己的话：

我是Jakub Majocha。我住在波兰克拉科夫，在那里我从事与软件无关的工作。我对计算机编程有着持久的兴趣，但我的经验仅限于小型一次性脚本、一些供内部使用和解决编程难题的工具，例如 Advent Of Code。我喜欢摆弄代码，并且我发现 F# 非常适合这样做。

事实上，我可以加入并为 F# 做出贡献，这表明社区是多么包容。这也归功于语言本身。F# 凭借其类型推断、简洁的语法和简单的仪式，允许快速实验、重构和尝试。对我来说这只是有趣和放松的事情。

总结

随着 11 月份最终版本的临近，我们的团队已经转向质量和完善工作。现在是报告您在 RC1 和早期版本中发现的任何问题的好时机。我们也很想听听您对使用这些功能的反馈。