Loading

【翻译】发布 .NET 8 Preview 1

本文使用 OpenAI gpt-3.5-turbo-0301 模型翻译生成

原文：Announcing .NET 8 Preview 1

欢迎使用 .NET 8！第一个预览版已经发布，您可以获取第一个 .NET 8 预览版并开始构建应用程序。请往下滑动以查看此预览版中包含的功能列表。.NET 8 是一次长期支持 (LTS) 发布。本博客文章介绍了主要的主题和目标，驱动开发过程中的增强选择和优先级。.NET 8 预览版和候选版本将每月发布。像往常一样，最终版本将在十一月的 .NET Conf 上发布。

Download .NET 8 Preview 1

.NET 的发布包括产品、库、运行时和工具，并代表着微软内外多个团队的协作。本博客文章涵盖的更广泛的主题并不涵盖 .NET 8 所有关键场景和投资。它们代表了大的领域，但只是所有重要工作的一部分。我们计划在 ASP.NET Core、Blazor、EF Core、WinForms、WPF 和其他平台上进行广泛的投资。您可以通过阅读产品路线图了解这些领域的更多信息：

请务必查看 themesof.net 以获取更多关于 .NET 8 跟踪的 GitHub 问题和里程碑的详细信息。

您可以下载适用于 Windows、macOS 和 Linux 的 .NET 8 预览版 1。

通过阅读我们的.NET 8 新功能文档，以了解最新和即将推出的内容，并会在发布期间不断更新。随着我们团队发布新的预览版，我们将包含其中已知特性的概要信息。

.NET 8 已经在 17.6 预览版 1 中进行了测试。如果想要尝试使用 .NET 8 和 Visual Studio 家族中的产品，请使用 预览通道版本。Visual Studio for Mac 对 .NET 8 预览版的支持目前不受支持。

欢迎使用 .NET 8

去年底，我们发布了 .NET 7，这是 .NET 团队和支持该版本的惊人社区之间合作的结果，超过 10,000 名社区成员提交了超过 28,000 次社区贡献。.NET 7 是今天构建应用程序的选择框架。该版本通过本地支持 ARM64 和增强对 Linux 的支持，将平台统一起来。它通过 .NET MAUI 这样的工具帮助你现代化你的应用程序，从而使得可以从同一代码库构建跨平台的移动应用程序和桌面应用程序。它提高了 API 的性能，并简化了构建和部署分布式云原生应用程序的体验。.NET 7 通过改进 C# 11 降低了构建应用程序所需代码量，使只需几行代码就可以创建和配置 API 成为可能。从帮助调试云 API 集成的开发隧道到直接从 .NET SDK 构建容器，开发者们可以从各种工具改进中获得更高的生产力。

在整个发布过程中，我们将更新 .NET 8 中的新功能。它将描述整个发布的关键特性，而博客文章将重点介绍每个预览版中的新功能。

您可以往下滑动以阅读我们在预览版 1 中发布的内容。首先，让我们展望一下 .NET 8 的愿景。

云原生开发者的最佳平台和工具

我们认为 .NET 开发者应该能够快速将他们的应用程序部署到云端，无需牺牲性能即可扩展其应用程序，并根据生产中关于您的应用程序的可行数据和反馈来进化它们。我们将投资于使得从本地开发和测试到持续集成和部署的全面端到端体验更加容易管理。我们的目标是使得实现微服务架构以及构建和部署容器更加容易。

云原生 是一个术语，用于描述专门用于在云计算环境中部署的应用程序的架构和设计。云原生背后的主要思想是利用云计算平台提供的优势，如可伸缩性、弹性和自我修复，创建高度可伸缩和弹性的应用程序。这允许灵活性并避免可能的过度投资硬件和软件以支持增长。许多开发者将云原生与微服务概念、容器编排（Kubernetes）和“-as-a-service”服务相联系。

使用 MAUI 和 Blazor 混合开发实现跨平台移动和桌面开发的极佳体验

在 .NET 7 时间范围内，我们发布了 .NET Multi-platform App UI (MAUI) SDK 和 Visual Studio 工具支持。.NET MAUI 提供了一个框架，用于创建运行 Android、iOS、macOS 和 Windows 的本地移动设备和桌面应用程序，并使用单个 C# 代码库。除了支持 XAML UI，您还可以使用 Blazor 构建混合应用程序，其中包含可访问原生设备平台并可在移动、桌面和 Web 上共享的 Razor UI 组件。.NET 团队计划在这些体验的基础上继续努力，专注于提高 SDK 和工具的质量、稳定性、性能和集成程度。

动力：基于您的反馈继续关注质量和性能

每个 .NET 的版本都包含对构成活跃和不断增长的 .NET 生态系统的 API、库和框架的性能、质量、稳定性和易用性的改进。其中许多改进是由客户和社区成员识别和优先排序的。.NET 8 将遵循同样的趋势，依靠您高度重视的反馈来帮助指导我们的愿景并推动我们的关注点。

保持最新状态

.NET 升级辅助工具是一款有价值的工具，可帮助开发者将其应用程序从旧版 .NET Framework 迁移到新版。这个工具的最新版本带有改进功能，支持新场景并处理更多情况。使用此工具，开发者现在可以轻松升级其应用程序到 .NET 6 或 .NET 7。

该工具可以自动检测并建议需要修改的代码，以确保与较新版本的框架兼容。此外，它可以处理更复杂的场景，例如升级使用第三方库的应用程序，并集成较新的平台功能。这些改进使得 .NET 升级辅助工具成为开发者们保持应用程序最新并利用最新 .NET 特性的必不可少的工具。这个工具集 最近被作为 Visual Studio 扩展引入了，以帮助您在 Visual Studio 的舒适环境中进行升级。

目标 .NET 8

要针对 .NET 8，首先需要确保从官方 Microsoft 网站安装了 .NET 8 SDK。接下来，可以创建一个新项目，在项目设置中设置适当的目标框架以指定要针对 .NET 8。

也可以通过更改项目属性来更新现有项目以针对 .NET 8。要做到这一点，请在 Visual Studio 或您喜欢的 IDE 中右键单击项目，选择“属性”，然后选择“应用程序”选项卡。从那里，可以选择要使用的目标框架版本。这将设置适当的目标框架：

<TargetFramework>net8.0</TargetFramework>

请注意，针对 .NET 8 可能需要更改您的代码或依赖项，因为与之前版本的 .NET 相比，API 或其他功能可能会发生变化。建议查看 .NET 8 的文档和发布说明，以确保您的代码和依赖项与新版本兼容。

.NET 8 预览版 1 中的新功能

我们的第一个预览版充满了今天可以尝试的新功能。以下是您可以期待的摘要。有关详细的发布说明和破坏性更改，请阅读 .NET 8。

原生 AOT

.NET 7 中已经发布了第一个 NativeAOT 功能，并针对控制台应用程序进行了优化。Ahead-of-Time（AOT）编译是 .NET 中一个重要的功能，它可以对 .NET 应用程序的性能产生显著影响。感谢 Adeel 和 Filip 在预览版 1 中为 macOS 带来了 NativeAOT 功能。.NET 团队将专注于完善一些基础知识，例如大小（请参见 dotnet/runtime#79003）。使用原生 AOT 发布应用程序会创建一个完全自包含的应用程序版本，因为所有内容都包含在一个文件中，所以不需要单独的运行时。在预览版 1 中，这个单文件更小了。实际上，Linux 构建现在缩小了多达 50%。

以下是包含整个 .NET 运行时的 Native AOT “Hello, World” 应用程序的大小：

.NET 7 .NET 8 预览版 1
Linux x64 (使用 -p:StripSymbols=true) 3.76 MB 1.84 MB
Windows x64 2.85 MB 1.77 MB

NativeAOT 将继续扩展并针对其他 .NET 8 应用方案，因此请继续关注此博客以获取未来的更新！

如果您对 AOT 不熟悉，以下是 AOT 提供的一些好处：

  • 减少内存占用：与 JIT 编译的代码相比，AOT 编译的代码需要更少的内存，因为 JIT 编译器会生成不需要在 AOT 编译应用程序中使用的中间代码。这对于具有有限内存的设备（如嵌入式系统和移动设备）尤其有益。
  • 提高启动速度：与 JIT 编译的代码相比，AOT 编译的代码启动速度更快，因为它消除了 JIT 编译器生成中间代码并针对特定硬件和软件环境优化代码的需求。这对于需要快速启动的应用程序（例如系统服务，无服务器“函数”和后台任务）尤其有益。
  • 延长电池寿命：与 JIT 编译的代码相比，AOT 编译的代码消耗的功率更少，因为它消除了 JIT 编译器生成中间代码并针对特定硬件和软件环境优化代码的需求。这对于依赖电池的设备（如移动设备）尤其有益。

.NET 容器镜像

.NET 开发人员可以使用容器镜像以轻量级、可移植的格式打包和部署应用程序，这些应用程序可在不同环境中运行，并且可以轻松地部署到云中。预览版 1 中包括以下改进，可以将容器镜像用于 .NET 应用程序：

更新默认 Linux 发行版为 Debian 12：.NET 容器镜像现在使用 Debian 12（Bookworm），我们预计将在2023年中期发布它。Debian 用于方便的标记，如 8.0，以及 Debian 特定的标记，如 8.0-bookworm-slim。

标记更改：.NET 8 预览版容器镜像将使用 8.0-preview 标记（而不是 8.0），并在发布候选版本时转换为 8.0。这种方法的目标是更清楚地描述预览版发布。此更改基于 社区请求 进行了制作。

以非root用户运行容器镜像：虽然容器基础镜像几乎总是配置为使用 root 用户运行 - 这是在生产中通常保持的设置，但这并不总是最好的方法。然而，为每个应用程序配置不同的用户很麻烦，并且容器镜像没有适用于容器工作负载的非 root 用户。

.NET 8 提供了更好的方法。从预览版 1 开始，我们发布的所有容器镜像都支持非 root 用户。以下是用于在 Dockerfiles 中以非 root 用户运行容器的单行示例：

USER app

此外，现在可以使用 -u app 启动容器镜像。默认端口已从端口 80 更改为 8080。这是一个破坏性更改，必须进行更改以启用非 root 场景，因为端口 80 是特权端口。

运行时和库

用于处理随机性的实用方法

System.Random 和 System.Security.Cryptography.RandomNumberGenerator 均已获得实用程序方法，用于从输入集中随机选择项目（“带替换”），称为 GetItems，以及用于随意排列跨度（span）的顺序，称为 Shuffle。

在机器学习中，Shuffle 通常用于减少训练偏差（因此第一件事不总是训练，最后一件事始终是测试）：

YourType[] trainingData = LoadTrainingData();
Random.Shared.Shuffle(trainingData);

IDataView sourceData = mlContext.Data.LoadFromEnumerable(trainingData);

DataOperationsCatalog.TrainTestData split = mlContext.Data.TrainTestSplit(sourceData);
model = chain.Fit(split.TrainSet);

IDataView predictions = model.Transform(split.TestSet);
...

我们来玩个游戏吧？试试 Simon？

private static ReadOnlySpan<Button> s_allButtons = new[]
{
    Button.Red,
    Button.Green,
    Button.Blue,
    Button.Yellow,
};

...

Button[] thisRound = Random.Shared.GetItems(s_allButtons, 31);
// rest of game goes here ...

System.Numerics 和 System.Runtime.Intrinsics

我们重新实现了 Vector256<T>，使其在可能的情况下内部成为 2x Vector128<T> 操作：dotnet/runtime#76221。当 Vector128.IsHardwareAccelerated == true 但 Vector256.IsHardwareAccelerated == false，例如在 Arm64 上时，这允许部分加速某些功能。

添加了 Vector512<T> 的初始托管实现：dotnet/runtime#76642。与前一个工作项类似，这在内部实现为 2x Vector256<T> 操作（因此间接地实现为 4x Vector128 操作）。即使 Vector512.IsHardwareAccelerated == false，这也允许部分加速某些功能。——注意：目前尚无直接加速 Vector512 的功能，即使底层硬件支持它。这种功能应该在未来的预览版中启用。

重写 Matrix3x2 和 Matrix4x4，以更好地利用硬件加速：dotnet/runtime#80091。这导致某些基准测试性能提高了多达 48 倍。 6-10x 的改进更加普遍。——注意：对 Quaternion 和 Plane 的改进将在 Preview 2 中推出。

硬件 Intrinsic 现在带有 ConstExpected 属性：dotnet/runtime#80192。这确保用户知道当底层硬件期望常量时，非常量值可能会意外地影响性能。

将 Lerp API 添加到 IFloatingPointIeee754<TSelf>，因此添加到 float (System.Single)、double (System.Double) 和 System.Half：dotnet/runtime#81186。这允许高效而正确地在两个值之间执行线性插值。

JSON 改进

我们不断提高 System.Text.Json 的性能和可靠性，重点是源代码生成器的性能和可靠性增强，如果它与 ASP.NET Core 在 NativeAOT 应用程序中一起使用。以下列表显示了 Preview 1 中发布的新功能：

  • 缺失成员处理 dotnet/runtime#79945

    现在可以配置对象反序列化行为，当底层 JSON 负载包含不能映射到反序列化的 POCO 类型成员的属性时。这可以通过设置 JsonUnmappedMemberHandling 值来控制，不仅可以作为 POCO 类型本身的注释，还可以全局设置在 JsonSerializerOptions 上或通过自定义相关类型的 JsonTypeInfo 合同进行编程控制：

    JsonSerializer.Deserialize<MyPoco>("""{"Id" : 42, "AnotherId" : -1 }"""); 
// JsonException : The JSON property 'AnotherId' could not be mapped to any .NET member contained in type 'MyPoco'.

[JsonUnmappedMemberHandling(JsonUnmappedMemberHandling.Disallow)]
public class MyPoco
{
   public int Id { get; set; }
}

  • 支持具有 required 和 init 属性的源代码生成器 dotnet/runtime#79828

    源代码生成器现在支持序列化具有必需和 init 属性的类型，就像目前在基于反射的序列化中支持的一样。

  • 接口层次结构支持 dotnet/runtime#78788

    System.Text.Json 现在支持从接口层次结构序列化属性：

    IDerived value = new Derived { Base = 0, Derived =1 };
JsonSerializer.Serialize(value); // {"Base":0,"Derived":1}

public interface IBase
{
  public int Base { get; set; }
}

public interface IDerived : IBase
{
  public int Derived { get; set; }
}

public class Derived : IDerived
{
  public int Base { get; set; }
  public int Derived { get; set; }
}

  • Snake Case 和 Kebab Case dotnet/runtime#69613

    该库现在随附了用于 snake_case 和 kebab-case 属性名称转换的命名策略。它们可以类似于现有的 camelCase 命名策略一样使用：

    var options = new JsonSerializerOptions { PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower };
JsonSerializer.Serialize(new { PropertyName = "value" }, options); // { "property_name" : "value" }

    现在可用以下命名策略：

    namespace System.Text.Json;

public class JsonNamingPolicy
{
  public static JsonNamingPolicy CamelCase { get; }
  public static JsonNamingPolicy KebabCaseLower { get; }
  public static JsonNamingPolicy KebabCaseUpper { get; }
  public static JsonNamingPolicy SnakeCaseLower { get; }
  public static JsonNamingPolicy SnakeCaseUpper { get; }
}

    感谢 @YohDeadfall 贡献了实现。

  • JsonSerializerOptions类一直使用着可冻结语义，但是直到现在冻结只能通过将实例隐式传递给JsonSerializer方法之一来完成。新增的API使得用户能够显式控制他们的JsonSerializerOptions实例何时应该被冻结：

    public class MySerializer
{
  private JsonSerializerOptions Options { get; }

  public MySerializer()
  {
        Options = new JsonSerializerOptions(JsonSerializerDefaults.Web) { Converters = { new MyCustomConverter() } };
        Options.MakeReadOnly(); // 在暴露属性之前将其设为只读。
  }
}

新的性能优化类型在核心库中

在核心库中添加了多个新类型，以便开发人员在常见场景中提高其代码的性能。

新的System.Collections.Frozen命名空间提供了FrozenDictionary<TKey, TValue>和FrozenSet<T>集合。这些类型提供了一个不可变表面区域，一旦创建，键或值就不允许更改。这反过来又使得这些集合能够更好地优化后续的读操作（例如TryGetValue），根据提供的数据选择花费更多时间来优化所有未来访问。这对于首次使用时填充集合，然后在长寿命服务的持续时间内进行持久化的集合特别有用，例如：

private static readonly FrozenDictionary<string, bool> s_configurationData =
    LoadConfigurationData().ToFrozenDictionary(optimizeForReads: true);
...
if (s_configurationData.TryGetValue(key, out bool setting) && setting)
{
    Process();
}

现有的ImmutableArray<T>.Builder类型还增加了一种将其内容有效地转换为ImmutableArray<T>的新方法。.NET 8引入了DrainToImmutable()，它会将当前内容作为不可变数组返回，并将构建器的集合重置为长度为零的数组，选择最有效的方法来执行此操作。可以使用此方法代替根据元素计数有条件地调用ToImmutable()或MoveToImmutable()。

另一个帮助开发人员在前期投入一点时间以换取后续更快执行的新类型的例子是新的IndexOfAnyValues<T>类型。除了像IndexOfAnyInRange这样的新方法外，还添加了接受IndexOfAnyValues<T>实例的IndexOfAny新重载，该实例可以被创建以表示要搜索的一组T值。创建此实例会处理派生出优化后续搜索所需的任何数据。例如，如果您经常搜索所有ASCII字母和数字以及一些标点符号字符，以前可能会编写：

private static readonly char[] s_chars = "-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz".ToCharArray();
...
int i = str.IndexOfAny(s_chars);

然而，这要么不进行任何矢量化以提高搜索的效率，要么需要在每次调用IndexOfAny时花费时间计算必要的状态以加速操作。现在，它可以改为：

private static readonly IndexOfAnyValues<char> s_chars = IndexOfAnyValues.Create("-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz");
...
int i = str.AsSpan().IndexOfAny(s_chars);

预先计算所有这些状态，并使其可供在每个后续IndexOfAny调用中复用。

这种模式在新的CompositeFormat类型中再次重复。.NET长期以来一直通过API（如string.Format和StringBuilder.AppendFormat）支持字符串格式化，例如：

static string GetMessage(int min, int max) =>
    string.Format(CultureInfo.InvariantCulture, "Range from {0} to {1}", min, max);

C# 6添加了对字符串插值的支持，然后C# 10与.NET 6一起显着提高了这些操作的效率，使得可以将相同的操作编写为：

static string GetMessage(int min, int max) =>
    string.Create(CultureInfo.InvariantCulture, $"Range from {min} to {max}");

但是，要在每次调用string.Format时预先计算所有可以预先计算的工作（例如解析格式字符串），而不是在运行时进行计算。但是，这要求在编译时已知格式字符串，以便可以在编译时解析它...如果直到运行时才知道格式字符串，例如从资源文件或其他动态方式加载，该怎么办？因此，.NET 8添加了CompositeFormat类型。就像IndexOfAnyValues<T>一样，它使得需要在每次使用时都要执行的操作可以被抬升出来只执行一次。

private static readonly CompositeFormat s_rangeMessage = CompositeFormat.Parse(LoadRangeMessageResource());
...
static string GetMessage(int min, int max) =>
    string.Format(CultureInfo.InvariantCulture, s_rangeMessage, min, max);

这些新的重载还支持通用参数，以避免由于将所有内容作为对象进行引用而产生的装箱开销。

.NET 8 Preview 1还添加了对新的性能优化哈希算法的支持，其中包括提供快速XXH3和XXH128哈希算法实现的新XxHash3和XxHash128类型。

.NET SDK

dotnet publish和dotnet pack默认生成Release资产

Publish和pack命令旨在生成生产资产，这意味着它们应该生成“Release”资产。在.NET 8中，默认情况下将执行此操作。人们已经要求这样做一段时间了。抱歉花费了这么长时间！

此功能由PublishRelease和PackRelease布尔属性控制。它们默认为true。

使用dotnet publish最容易演示该功能：

/app# dotnet new console
/app# dotnet build
app -> /app/bin/Debug/net8.0/app.dll
/app# dotnet publish
app -> /app/bin/Release/net8.0/app.dll
app -> /app/bin/Release/net8.0/publish/
/app# dotnet publish -p:PublishRelease=false
app -> /app/bin/Debug/net8.0/app.dll
app -> /app/bin/Debug/net8.0/publish/

请注意，PublishRelease和PackRelease在.NET 7中也存在，从SDK 7.0.200开始可用。它们在.NET 7中是选择加入的，并且必须设置为true才能提供相同的行为。

请参见破坏性更改文档：

Linux支持

在dotnet/dotnet上构建自己的.NET

现在可以直接从dotnet/dotnet存储库在Linux上构建.NET。它使用 dotnet/source-build来构建.NET运行时、工具和SDK，这是Red Hat和Canonical用于构建.NET的相同构建。随着时间的推移，我们将扩展其支持macOS和Windows。

请参见构建说明以在本地机器上构建VMR。由于我们的dotnet-buildtools/prereqs容器映像包含所有必需的依赖项，因此在容器中构建对许多人来说是最简单的方法。

我们称这个新存储库为虚拟Mono存储库（VMR）。它具有真正的单一存储库的优点，但是是每天贡献者工作中现有存储库的定期更新投影，更加有效。我们认为，VMR和规模较小的“工作存储库”之间的分离是.NET项目的未来。我们预计跨越功能将更易于在VMR中构建，但我们还没有到那一步。

我们认为这种新方法是.NET整体产品从源代码构建中可接近性的重大进步。

在.NET 8之前，从源代码构建是可能的，但需要从与发布对应的dotnet/installer提交创建“源代码tarball”。现在不再需要了。存储库将具有对应于每个发布版本的标签，以及持续跟踪产品状态的main和release/8.0-previewN分支。

.NET 8 + Ubuntu Chiseled容器映像

我们正在发布带有.NET 8的Ubuntu Chiseled映像。这种类型的映像适用于希望获得比常规容器更多的设备式计算优势的开发人员。我们预计，在.NET 8发布时，Canonical和Microsoft都会支持Ubuntu Chiseled映像的生产环境。

我们计划从.NET 8开始，将dotnet/monitor映像专门作为Ubuntu Chiseled发布。这很重要，因为监视器映像是我们发布的唯一一种生产应用程序映像。

Chiseled映像具有许多优点：

  • 超小的映像（减少了大小和攻击面）
  • 没有软件包管理器（避免了整个攻击类别）
  • 没有shell（避免了整个攻击类别）
  • 非root用户（避免了整个攻击类别）

您可以查看使用我们的aspnetapp示例生成chiseled映像的模式。它只需要一行更改即可完成。

目前，Chiseled映像已发布到我们的nightly库中，适用于.NET 6和.NET 7版本。

Linux支持和基线目标

我们正在更新.NET 8 Linux的最小基线。有三个显著的变化。

  • .NET产品将针对Ubuntu 16.04的所有架构进行构建。这主要是为了定义.NET 8的最小glibc版本。例如，由于此更改，.NET 8将无法在Ubuntu 14.04上启动。
  • 对于Red Hat Enterprise Linux（RHEL），我们将支持RHEL 8+，放弃RHEL 7。
  • 我们只会发布对RHEL的支持声明，但我们打算将该支持应用于其他RHEL生态系统发行版。

没有其他重大变化。我们将继续支持Arm32、Arm64和x64架构的Linux。

请注意，这些更改仅适用于Microsoft构建。使用source-build的组织将做出不同的选择，通常会生成一个仅适用于一个发行版版本（如Ubuntu 24.04）的构建。

以下演示了Ubuntu 16.04的glibc版本以及用于发现其他发行版版本的模式。

$ docker run --rm ubuntu:16.04 ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu11.3) 2.23
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
posted @ 2023-03-09 19:30  晓晨Master  阅读(506)  评论(0)  编辑  收藏  举报