【翻译】.NET 5 Preview8发布

【翻译】.NET 5 Preview8发布

今天，.NET 5预览8发布了，对于.NET5.0的功能开发已经完成了，这必需要排除待处理的bug，预览8是最后一次预览版本。预计11月正式的.NET5.0版本发布以前还将发布两个正式以前的候选版本，这篇文章描述了.NET5.0版本中的一系列功能。
You can download .NET 5.0, for Windows, macOS, and Linux:

• Installers and binaries
• Container images
• Snap installer
• Release notes
• Known issues
• GitHub issue tracker

今天同时也发布了ASP.NET Core 和 EF Core 。
要使用.NET5咱们须要最新版本的 Visual Studio (包括 Visual Studio for Mac) 才能使用 .NET 5.0.
.NET 5.0包括许多改进，特别是单个文件应用程序，较小的容器映像，更强大的JsonSerializer API，一整套可空的引用类型注释以及对Windows ARM64的支持。 在NET库，GC和JIT中，性能获得了极大的提升。 ARM64是性能投资的重点，可提升吞吐量并减小二进制文件。 .NET 5.0包括新的语言版本C＃9和F＃5.0。
.NET 5.0包括了许多的改进，特别是单个文件应用程序，较小的容器映像，更强大的JsonSerializer APIs，一整套可空的引用类型注释以及对Windows ARM64的支持。在.NET库，GC和JIT中，性能获得了极大的提升，ARM6是性能的重点项，可提升吞吐量并减小二进制文件。.NET5.0包括新的语言版本C# 9 和F# 5.0.


如今这个版本功能开发已经完成，让咱们看一下.NET5.0的一部分，该帖子由一组主题部分组成：语言，工具、API、运行时技术和应用程序部署。这些部分及其顺序大体反映了开发过程和生命周期，若是您对一个开发方面对比另外一个方面更敢兴趣，这将帮助您找到所需的内容。

Languages

C#9和F#5是.NET5.0版本的一部分，并包含在.NET5.0 SDK中，Visual SDK也包含了在5.0 SDK中，它不包括语言的更改，但进行了改进以支持.NET Core上的Visual Basic应用程序框架。
C#源码生成器是一项重要的新c#编译器新功能，因为它没有任何语言语法，所以在技术上不属于C#9，请参阅新的c#源代码生成器示例，以帮助您开始使用此新功能。

C# 9

c#9是该语言的重要版本，这个版本专一于程序的简单性，数据不变形和更多的模式.

Top-level programs

高级的程序提供了更简单的语法，而仪式感却变少了，此语法将首先帮助咱们学习该语言，咱们但愿高级程序语法在后续发行版中变得更加简单，例如删除默认的 using 语句
下面是c# 9版本的“hello world”。

using System;

Console.WriteLine("Hello World!");

高级的程序能够扩展为使用更多功能，例如在同一文件中定义和调用方法或者类.

using System;
using System.Runtime.InteropServices;
Console.WriteLine("Hello World!");
FromWhom();
Show.Excitement("Top-level programs can be brief, and can grow as slowly or quickly in complexity as you'd like", 8);
void FromWhom()
{
    Console.WriteLine($"From {RuntimeInformation.FrameworkDescription}");
}
internal class Show
{
    internal static void Excitement(string message, int levelOf)
    {
        Console.Write(message);
        for (int i = 0; i < levelOf; i++)
        {
            Console.Write("!");
        }
        Console.WriteLine();
    }
}

该程序生成如下输出。

[rich@taumarunui test]$ ~/dotnet/dotnet run
Hello World!
From .NET 5.0.0-preview.8
Top-level programs can be brief, and can grow as slowly or quickly in complexity as you'd like!!!!!!!!

Pattern matching

Patterns test值具备特定的形状，并在其具备匹配形状时能够从值中提取信息。最新的c#版本中已添加了新的模式匹配改进。
我将分享两个示例，第一个演示了属性的模式，在将上下文对象与特定模式进行比较以前，他会检查是否为null（带有is）.

if (context is {IsReachable: true, Length: > 1 })
{
    Console.WriteLine(context.Name);
}
This is equivalent to:
if (context is object && context.IsReachable && context.Length > 1 )
{
    Console.WriteLine(context.Name);
}
Also equivalent to:
if (context?.IsReachable && context?.Length > 1 )
{
    Console.WriteLine(context.Name);
}

如下示例使用relational patterns（如<,<=）和逻辑模式(如and,or和not)。如下代码根据毛重计算出送货的卡车在高速公路的通行费（decimal ），对于那些不熟悉的人，在数字文字告诉编译器以后,m表示数字是decimal 而不是double.

DeliveryTruck t when t.GrossWeightClass switch
{
    < 3000 => 8.00m,
    >= 3000 and <= 5000 => 10.00m,
    > 5000 => 15.00m,
},

Target-typed new expressions
Target-typed new expressions是在构造对象/值时移除类型重复的一种新方法。
下面的示例都是等效的，中间是新的语法。

List<string> values = new List<string>();
List<string> values = new();
var values = new List<string>();

我猜不少人都会喜欢这个新语法 var 有两个缘由：许多人阅读从左到右和但愿的类型信息左边 = ，可能更重要的是左边的事彻底致力于类型信息，而不是被一个特定的构构造函数的复杂性和细微差异（右边）

Tools

在这篇文章中，咱们将重点关注运行时诊断工具。

Microsoft.Extensions.Logging

咱们对Microsoft.Extensions.Logging 库中的控制台日志提供程序进行了改进，开发人员如今能够实现自定义的[ConsoleFormatt](https://github.com/dotnet/runtime/issues/34742) ，以彻底控制控制台输出的格式和颜色，格式化程序API经过实现 VT-100 (大多数现代终端支持)转移序列的子集来实现丰富的格式化，控制台记录器能够解析不受支持的终端上的转义序列，使您能够为全部终端编写单个格式化程序。
除了支持自定义格式化程序外，咱们还添加了一个内置的JSON格式化程序，它会将结构化JSON日志发送到控制台。

Dump debugging

调试托管代码须要对托管对象和构造有特殊的了解，数据访问组件（DAC）事运行时执行引擎的子集，他具备这些构造的知识，而且能够在没有运行时的状况下访问这些托管对象，从Preview 8开始，他们已经开始针对Windows编译Linux DAC，如今可使用WinDBG或 dotnet dump analysis 在Windows上分析在Linux上收集的.NET Core进程转储。
在Preview 8中，咱们还添加了对从macOS上运行的.NET进程捕获ELF转储的支持，因为ELF并非macOS上的本机可执行文件（像 lldvb 这样本地调试器将不适用于这些转储）文件格式，所以咱们将其设为可选功能，要在macOS上启用对转储收集的支持，请设置环境变量COMPlus_DbgEnableElfDumpOnMacOS=1 可使用 dotnet dump analyze对生成的dump进行分析

Assembly load diagnostics added to event pipe

咱们向事件管道添加了程序集加载信息，您能够将其视为Fusion Log Viewer的替代品，如今您可使用 dotnet-trace 经过如下命令来收集此信息

Microsoft-Windows-DotNETRuntime:4:4 --process-id [process ID]

Printing environment information

随着.NET扩展了对新操做系统和芯片体系结构的支持，人们有时须要一种打印环境信息的方法，咱们建立了一个简单的.NET工具成为dotnet-runtimeinfo.
您可使用如下命令安装和运行该工具

dotnet tool install -g dotnet-runtimeinfo
dotnet-runtimeinfo

该工具为您的环境生成如下形式的输出

[rich@taumarunui ~]$ dotnet-runtimeinfo
.NET information
Version: 5.0.0
FrameworkDescription: .NET 5.0.0-preview.8.20407.11
Libraries version: 5.0.0-preview.8.20407.11
Libraries hash: bf456654f9a4f9a86c15d9d50095ff29cde5f0a4
**Environment information
OSDescription: Linux 5.8.3-2-MANJARO-ARM #1 SMP Sat Aug 22 21:00:07 CEST 2020
OSVersion: Unix 5.8.3.2
OSArchitecture: Arm64
ProcessorCount: 6
**CGroup info
cfs_quota_us: -1
memory.limit_in_bytes: 9223372036854771712
memory.usage_in_bytes: 2945581056

Library APIs

在.NET5.0中添加并改进了许多新的api，下面是一些重要的变化，须要注意。

Nullable Annotations

可空引用类型是c#8和.NET Core3.0的重要功能，他的发布充满了但愿，但缺乏详细的平台注释，以使其真正有用且使用，等待（大部分）结束了，如今该平台已为可控性添加了80%的注释，他们正在研究是否能够在发布.NET5.0 RTM以前注释剩余的20%若是没有，他们将在.NET6.0的早期完成其他的注释。

下图展现了他们这段时间内取得的进展。

这也意味着，当您将现有的.NET Core3.1代码从新定位到.NET 5.0时，可能会生成新的诊断（若是启用了可空性），若是发生这种状况，您能够感谢咱们帮助您避免使用 null 

Regular expression performance improvements

咱们对Regex引擎进行了重大的改进，在他们尝试过许多表达式中，这些改进一般会让吞吐量提升3-6倍，在某些状况下甚至更多，他们在System.Text.RegularExpressions 中所作的更改。常常的压力已经对他们本身的使用产生了可衡量的影响。他们但愿这些改进也能在你的库和应用程序中带来可衡量的胜利

.NET 5.0 Target Framework

咱们正在改变，.NET5.0目标框架的使用方法，下面的项目文件演示了新的.NET5.0目标框架

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>
</Project>

到目前为止，新的.NET5.0表单比咱们使用netcoreapp3.1样式更紧凑，更直观。此外他们正在将目标框架扩展为操做系统进行建模。他们但愿经过.NET6.0中的Xamarin定位IOS和Android,从而推进这一变化。
Windows桌面API仅在面向net5.0-windows 时可用，您能够指定操做系统版本，例如 net5.0-windows7或 net5.0-windows10.17763 (October 2018 Update) ，若是要使用WinRT APIs.，则须要定位Windows10版本。
变更汇总：

• net5.0 is the new Target Framework Moniker (TFM) for .NET 5.0.
• net5.0 combines and replaces netcoreapp and netstandard TFMs.
• net5.0 supports .NET Framework compatibility mode
• net5.0-windows will be used to expose Windows-specific functionality, like Windows Forms and WPF.
• .NET 6.0 will use the same approach, with net6.0 and will add net6.0-ios and net6.0-android.
• The OS-specific TFMs can include OS version numbers, like net6.0-ios14.
• Portable APIs, like ASP.NET Core and Xamarin.Forms, will be usable with net5.0.
  

WinRT Interop (Breaking Change)

咱们已经移至一个新模型，做为.NET5.0的一部分，他支持WinRT API,这包括调用API（在任一方向上; CLR <==> WinRT）,两个类型系统之间的数据封送处理以及旨在跨越边界被视为相同类型的统一(既“projected types”; IEnumerable<T> 和 IIterable<T> 是示例)
他们将以来WinRT团队在Windows中提供的一套新的WinRT工具，他将生成基于c#的WinRT互操做程序集

新的WinRT互操做系统有几个好处:

• It can be developed and improved separate from the .NET runtime.
• Symmetrical with interop systems provided for other OSes, like iOS and Android.
• Can take advantage of many other .NET features (AOT, C# features, IL linking).
• Simplifies the .NET runtime codebase.

现有的WinRT互操做系统已经做为.NET5.0的一部分，从.NET运行时（以及任何其余相关组件）中删除，这是一个突破性的变化，这将意味者使用WinRT和.NET Core3.x 应用程序须要从新构建，不能按照原样在.NET5上运行。

Runtime Technology

在.NET5.0中添加了许多新特性。下面介绍一小部分选择。

Windows ARM64

咱们在这个版本中增长了对Windows ARM64的支持。咱们已经作出了相对较晚的决定，推迟Windows桌面组件(Windows Forms, WPF)的发布。Windows窗体已接近就绪，但WPF尚未，并且咱们不想只发布Windows桌面组件的一半，部分缘由是咱们没有在分割配置中测试它。咱们但愿在5.0服务更新中添加Windows桌面组件。
咱们正在与一些ISV合做，他们但愿其应用程序在Windows ARM64上可用。 若是符合您的状况，请经过dotnet@microsoft.com与咱们联系。 咱们但愿尽快为您提供构建版本。

Event pipe profiler APIs

事件管道是在.NET Core 2.2中添加的新子系统和API，能够在任何操做系统上执行性能和其余诊断调查。 在.NET 5.0中，事件管道已获得扩展，以使事件探查器可以写入事件管道事件。 对于之前依靠ETW监视应用程序行为和性能的分析探查器，此方案相当重要。

Native exports

您如今能够将托管方法导出到本机代码。 该功能的构建块是托管对UnmanagedCallersOnlyAttribute的API支持。

开发团队的Aaron Robinson一直在从事.NET Native Exports项目，该项目为将.NET组件做为本机库发布提供了更完整的体验。 咱们正在寻求有关此功能的反馈，以帮助决定是否在更高版本中将该方法包括在产品中。

有一些现有的项目能够实现相似的场景，例如:

• Unmanaged Exports
• DllExport
  

Application deployment

编写或更新应用程序后，您须要对其进行部署以供用户利用。 在此版本中，咱们专一于单个文件应用程序，并改进了.NET Core的ClickOnce。

Single file applications

单个文件应用程序做为单个文件发布和部署。 该应用程序及其依赖项都包含在该文件中。 当应用程序运行时，依赖项直接从该文件加载到内存中。 这种方法不会下降性能。 当与程序集修剪和提早编译结合使用时，单个文件应用程序将变得更小，启动速度更快。
在.NET 5.0中，单个文件应用程序主要集中在Linux上（稍后会详细介绍）。 它们能够是框架相关的，也能够是独立的。 依赖于全局安装的.NET运行时，依赖于框架的单个文件应用程序可能很小。 自包含的单文件应用程序更大（因为带有运行时），可是不须要做为安装前步骤就安装.NET运行时，所以能够正常工做。 一般，依赖框架对开发和企业环境有利，而对于ISV，独立包含一般是更好的选择。
咱们使用.NET Core 3.1制做了一个单文件应用程序版本。 它将二进制文件打包到一个文件中以进行部署，而后将这些文件解压缩到一个临时目录中以加载并执行它们。 在某些状况下，这种方法可能会更好，可是咱们但愿咱们为5.0构建的解决方案将是首选，而且会受到欢迎。
建立真正的单文件解决方案须要克服多个障碍。 咱们必须建立一个更复杂的应用程序捆绑器，教导运行时从二进制资源中加载程序集，并使调试器与内存映射的程序集兼容。 咱们还遇到了一些咱们没法清除的障碍。

在全部平台上，咱们都有一个名为“ apphost”的组件。 这是成为可执行文件的文件，例如Windows上的 myapp.exe 或基于Unix平台上的 ./myapp 。 对于单文件应用程序，咱们建立了一个新主机，称为“超级主机”。 它具备与常规apphost相同的角色，但还包含运行时的静态连接副本。 超级主机是咱们单文件方法的基本设计要点。 此模型是咱们在Linux上使用的模型。 因为各类操做系统限制，咱们没法在Windows或macOS上实现此方法。 在Windows或macOS上没有超级主机。 在这些操做系统上，本机运行时二进制文件（约3个）位于单个文件应用程序旁边。 咱们将在.NET 6.0中从新审视这种状况，可是，咱们但愿遇到的问题仍然具备挑战性。

您可使用如下命令生成单文件应用程序。

• Framework-dependent single-file app:
  • dotnet publish -r linux-x64 --self-contained false /p:PublishSingleFile=true
• Self-contained single-file app with assembly trimming and ready to run enabled:
  • dotnet publish -r linux-x64 --self-contained true /p:PublishSingleFile=true /p:PublishTrimmed=true /p:PublishReadyToRun=true

您还可使用项目文件配置单个文件发布。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <!-- Enable single file -->
    <PublishSingleFile>true</PublishSingleFile>
    <!-- Determine self-contained or framework-dependent -->
    <SelfContained>true</SelfContained>
    <!-- The OS and CPU type you are targeting -->
    <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
    <!-- Enable use of assemby trimming - only supported for self-contained apps -->
    <PublishTrimmed>true</PublishTrimmed>
    <!-- Enable AOT compilation -->
    <PublishReadyToRun>true</PublishReadyToRun>
  </PropertyGroup>
</Project>

Notes:

• Apps are OS and architecture-specific. You need to publish for each configuration (Linux x64, Linux ARM64, Windows x64, …).
• Configuration files (like *.runtimeconfig.json) are included in the single file. You can place an additional config file beside the single file, if needed (possibly for testing).
• .pdb files are not included in the single file by default. You can enable PDB embedding with the <DebugType>embed</DebugType> property.

咱们在之前的预览文章中看到了不少评论，询问有关单个文件应用程序与提早（AOT）编译之间的关系。 AOT是一个频谱。 dotnet发布生成的现成代码（将 PublishReadyToRun 设置为true时）是AOT的示例。 当您发布准备运行的映像时，该构建会提早为您生成机器代码，而不是在运行时由JIT生成。 大多数人可能会将其做为AOT的定义。 可是，许多人说AOT时的意思更具体。 他们想要一种具备如下特征的解决方案：启动速度极快，不存在IL（出于大小和混淆的缘由），（最多）JIT是可选的，而且二进制大小尽量小。 咱们使用术语“本机AOT”来描述AOT频谱上的该点。 .NET 5.0中提供的单个文件解决方案不知足AOT的这必定义。 这是一大进步，但不是“本地AOT”。 咱们最近发布了有关本机AOT的调查，以获取有关该模式的更多反馈。 咱们正在仔细研究结果，并将其归入咱们的6.0计划工做中。

Reducing the size of container images

咱们一直在寻找使.NET容器映像更小且更易于使用的机会。 咱们将SDK映像从新创建在ASP.NET映像之上，而不是buildpack-deps上，以显着减少您在多阶段构建方案中提取的聚合映像的大小

对于多阶段构建，此更改具备如下优点（Dockerfile中的示例用法）
Multi-stage build costs with Ubuntu 20.04 Focal:

Pull Image	Before	After
sdk:5.0-focal	268 MB	232 MB
aspnet:5.0-focal	64 MB	10 KB (manifest only)

Net download savings: 100 MB (-30%)
Multi-stage build costs with Debian 10 Buster:

Pull Image	Before	After
sdk:5.0	280 MB	218 MB
aspnet:5.0	84 MB	4 KB (manifest only)

Net download savings: 146 MB (-40%)
See dotnet/dotnet-docker #1814 for more detailed information.


此更改有助于多阶段构建，其中目标的sdk和aspnet或运行时映像是同一版本（咱们但愿这是常见的状况）。 进行此更改后，aspnet pull（例如）将变为无操做状态，由于您将经过初始sdk pull来拉伸aspnet层。
咱们对Alpine和Nano Server进行了相似的更改。 对于Alpine或Nano Server，没有 buildpack-deps 映像。 可是，Alpine和Nano Server的sdk映像之前未在ASP.NET映像之上构建。 咱们解决了。 对于多阶段构建，您将看到Alpine和Nano Server以及5.0的巨大成功。

ClickOnce Support

几个月前，咱们宣布将为.NET Core提供ClickOnce支持。 该项目仍在进行中。 咱们但愿将其做为RC2的一部分提供。 我只是想分享一下咱们仍在从事此项目。

Closing

在发行版中，“关闭”是一个有趣的章节标题。 该发布确实即将结束。 该团队致力于解决全部剩余的5.0问题，并在发行版中得到最终的错误修复和改进。 甚至5.0 Runtime Epics问题也已解决。咱们正在研究一些深刻的帖子，咱们计划在有关各类主题的最终版本发布以前发布这些帖子。 注意那些。 您还能够指望最终版本的发布时间更长，涵盖更普遍的改进和功能。感谢您对本发行版的全部支持以及所作的全部贡献。