【翻譯】.NET 5 Preview8發(fā)布

今天，.NET 5預(yù)覽8發(fā)布了，對于.NET5.0的功能開發(fā)已經(jīng)完成了，這必須要排除待處理的bug，預(yù)覽8是最后一次預(yù)覽版本。預(yù)計11月正式的.NET5.0版本發(fā)布之前還將發(fā)布兩個正式之前的候選版本，這篇文章描述了.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

今天同時也發(fā)布了ASP.NET Core 和 EF Core 。
要使用.NET5我們需要最新版本的?Visual Studio?(包括?Visual Studio for Mac)?才能使用 .NET 5.0.
.NET 5.0包括許多改進，特別是單個文件應(yīng)用程序，較小的容器映像，更強大的JsonSerializer API，一整套可空的引用類型注釋以及對Windows ARM64的支持。在NET庫，GC和JIT中，性能得到了極大的提高。ARM64是性能投資的重點，可提高吞吐量并減少二進制文件。.NET 5.0包括新的語言版本C＃9和F＃5.0。
.NET 5.0包括了許多的改進，特別是單個文件應(yīng)用程序，較小的容器映像，更強大的JsonSerializer APIs，一整套可空的引用類型注釋以及對Windows ARM64的支持。在.NET庫，GC和JIT中，性能得到了極大的提高，ARM6是性能的重點項，可提高吞吐量并減少二進制文件。.NET5.0包括新的語言版本C# 9 和F# 5.0.


.NET 5.0還包括使用Mono運行時和.NET庫對Web程序集的支持。這是.NET 5.0中Blazor Web程序集的基礎(chǔ)。這是對Blazor 3.2的更改，后者使用了Mono運行時庫和Mono庫。去年，我們提出了一個統(tǒng)一的.NET平臺的愿景，該平臺具有適用于所有.NET應(yīng)用程序類型的一組庫和工具。此項更改的好處是，可以享受.NET的單一開發(fā)經(jīng)驗，可以在各種.NET應(yīng)用類型之間實現(xiàn)更高的兼容性，并且僅維護和改進一個代碼庫。我們使用Web程序集進行的更改（使用.NET庫）是對該愿景的首付。我們期望通過.NET 6.0實現(xiàn)其余的愿景，主要集中在Xamarin（iOS和Android）上。
.NET 5.0 還包括使用Mono運行時和.NET庫對Web程序集的支持，這是.NET 5.0中Blazor Web程序集的基礎(chǔ)。這是對Blazor 3.2的更改，后者使用了Mono運行時和Mono庫，在去年他們提出了一個統(tǒng)一的.NET平臺的愿景，該平臺具有適用于所有.NET應(yīng)用程序類型的一組庫和工具，此項更改的好處是，可以享受.NET的單一開發(fā)經(jīng)驗，可以在各種的.NET應(yīng)用類型之間實現(xiàn)更高的兼容性，并且僅維護和改進一個代碼庫，在這次使用Web程序集進行的更改（使用.NET庫）是對該愿景的首次交付，希望能通過.NET6.0實現(xiàn)其余的愿景，主要集中在Xamarin（iOS和Android）上。
現(xiàn)在這個版本功能開發(fā)已經(jīng)完成，讓我們看一下.NET5.0的一部分，該帖子由一組主題部分組成：語言，工具、API、運行時技術(shù)和應(yīng)用程序部署。這些部分及其順序大致反映了開發(fā)過程和生命周期，如果您對一個開發(fā)方面對比另一個方面更敢興趣，這將幫助您找到所需的內(nèi)容。

Languages

C#9和F#5是.NET5.0版本的一部分，并包含在.NET5.0 SDK中，Visual SDK也包含了在5.0 SDK中，它不包括語言的更改，但進行了改進以支持.NET Core上的Visual Basic應(yīng)用程序框架。
C#源碼生成器是一項重要的新c#編譯器新功能，由于它沒有任何語言語法，因此在技術(shù)上不屬于C#9，請參閱新的c#源代碼生成器示例，以幫助您開始使用此新功能。

C# 9

c#9是該語言的重要版本，這個版本專注于程序的簡單性，數(shù)據(jù)不變形和更多的模式.

Top-level programs

高級的程序提供了更簡單的語法，而儀式感卻變少了，此語法將首先幫助我們學(xué)習(xí)該語言，我們希望高級程序語法在后續(xù)發(fā)行版中變得更加簡單，例如刪除默認的?using?語句
下面是c# 9版本的“hello world”。

using System;

Console.WriteLine("Hello World!");

高級的程序可以擴展為使用更多功能，例如在同一文件中定義和調(diào)用方法或者類.

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)。以下代碼根據(jù)毛重計算出送貨的卡車在高速公路的通行費（decimal?），對于那些不熟悉的人，在數(shù)字文字告訴編譯器之后,m表示數(shù)字是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是在構(gòu)造對象/值時移除類型重復(fù)的一種新方法。
下面的示例都是等效的，中間是新的語法。

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

我猜很多人都會喜歡這個新語法?var?有兩個原因：許多人閱讀從左到右和希望的類型信息左邊?=?，可能更重要的是左邊的事完全致力于類型信息，而不是被一個特定的構(gòu)構(gòu)造函數(shù)的復(fù)雜性和細微差別（右邊）

Tools

在這篇文章中，我們將重點關(guān)注運行時診斷工具。

Microsoft.Extensions.Logging

我們對Microsoft.Extensions.Logging?庫中的控制臺日志提供程序進行了改進，開發(fā)人員現(xiàn)在可以實現(xiàn)自定義的[ConsoleFormatt](https://github.com/dotnet/runtime/issues/34742)?，以完全控制控制臺輸出的格式和顏色，格式化程序API通過實現(xiàn)?VT-100?(大多數(shù)現(xiàn)代終端支持)轉(zhuǎn)移序列的子集來實現(xiàn)豐富的格式化，控制臺記錄器可以解析不受支持的終端上的轉(zhuǎn)義序列，使您可以為所有終端編寫單個格式化程序。
除了支持自定義格式化程序外，我們還添加了一個內(nèi)置的JSON格式化程序，它會將結(jié)構(gòu)化JSON日志發(fā)送到控制臺。

Dump debugging

調(diào)試托管代碼需要對托管對象和構(gòu)造有特殊的了解，數(shù)據(jù)訪問組件（DAC）事運行時執(zhí)行引擎的子集，他具有這些構(gòu)造的知識，并且可以在沒有運行時的情況下訪問這些托管對象，從Preview 8開始，他們已經(jīng)開始針對Windows編譯Linux DAC，現(xiàn)在可以使用WinDBG或?dotnet dump analysis?在Windows上分析在Linux上收集的.NET Core進程轉(zhuǎn)儲。
在Preview 8中，我們還添加了對從macOS上運行的.NET進程捕獲ELF轉(zhuǎn)儲的支持，由于ELF并不是macOS上的本機可執(zhí)行文件（像?lldvb?這樣本地調(diào)試器將不適用于這些轉(zhuǎn)儲）文件格式，因此我們將其設(shè)為可選功能，要在macOS上啟用對轉(zhuǎn)儲收集的支持，請設(shè)置環(huán)境變量COMPlus_DbgEnableElfDumpOnMacOS=1?可以使用?dotnet?dump analyze對生成的dump進行分析

Assembly load diagnostics added to event pipe

我們向事件管道添加了程序集加載信息，您可以將其視為Fusion Log Viewer的替代品，現(xiàn)在您可以使用?dotnet-trace?通過以下命令來收集此信息

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

Printing environment information

隨著.NET擴展了對新操作系統(tǒng)和芯片體系結(jié)構(gòu)的支持，人們有時需要一種打印環(huán)境信息的方法，我們創(chuàng)建了一個簡單的.NET工具成為dotnet-runtimeinfo.
您可以使用以下命令安裝和運行該工具

dotnet tool install -g dotnet-runtimeinfo
dotnet-runtimeinfo

該工具為您的環(huán)境生成以下形式的輸出

[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的重要功能，他的發(fā)布充滿了希望，但缺少詳細的平臺注釋，以使其真正有用且使用，等待（大部分）結(jié)束了，現(xiàn)在該平臺已為可控性添加了80%的注釋，他們正在研究是否可以在發(fā)布.NET5.0 RTM之前注釋剩余的20%如果沒有，他們將在.NET6.0的早期完成其余的注釋。

下圖展示了他們這段時間內(nèi)取得的進展。

這也意味著，當您將現(xiàn)有的.NET Core3.1代碼重新定位到.NET 5.0時，可能會生成新的診斷（如果啟用了可空性），如果發(fā)生這種情況，您可以感謝我們幫助您避免使用?null?

Regular expression performance improvements

我們對Regex引擎進行了重大的改進，在他們嘗試過許多表達式中，這些改進通常會讓吞吐量提高3-6倍，在某些情況下甚至更多，他們在System.Text.RegularExpressions?中所做的更改。經(jīng)常的壓力已經(jīng)對他們自己的使用產(chǎn)生了可衡量的影響。他們希望這些改進也能在你的庫和應(yīng)用程序中帶來可衡量的勝利

.NET 5.0 Target Framework

我們正在改變，.NET5.0目標框架的使用方法，下面的項目文件演示了新的.NET5.0目標框架

"Microsoft.NET.Sdk">
  
    Exe
    net5.0
  

到目前為止，新的.NET5.0表單比我們使用netcoreapp3.1樣式更緊湊，更直觀。此外他們正在將目標框架擴展為操作系統(tǒng)進行建模。他們希望通過.NET6.0中的Xamarin定位IOS和Android,從而推動這一變化。
Windows桌面API僅在面向net5.0-windows?時可用，您可以指定操作系統(tǒng)版本，例如?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)

我們已經(jīng)移至一個新模型，作為.NET5.0的一部分，他支持WinRT API,這包括調(diào)用API（在任一方向上; CLR <==> WinRT）,兩個類型系統(tǒng)之間的數(shù)據(jù)封送處理以及旨在跨越邊界被視為相同類型的統(tǒng)一(既“projected types”;?IEnumerable?和?IIterable?是示例)
他們將以來WinRT團隊在Windows中提供的一套新的WinRT工具，他將生成基于c#的WinRT互操作程序集

新的WinRT互操作系統(tǒng)有幾個好處:

• 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.

現(xiàn)有的WinRT互操作系統(tǒng)已經(jīng)作為.NET5.0的一部分，從.NET運行時（以及任何其他相關(guān)組件）中刪除，這是一個突破性的變化，這將意味者使用WinRT和.NET Core3.x 應(yīng)用程序需要重新構(gòu)建，不能按照原樣在.NET5上運行。

Runtime Technology

在.NET5.0中添加了許多新特性。下面介紹一小部分選擇。

Windows ARM64

我們在這個版本中增加了對Windows ARM64的支持。我們已經(jīng)做出了相對較晚的決定，推遲Windows桌面組件(Windows Forms, WPF)的發(fā)布。Windows窗體已接近就緒，但WPF還沒有，而且我們不想只發(fā)布Windows桌面組件的一半，部分原因是我們沒有在分割配置中測試它。我們希望在5.0服務(wù)更新中添加Windows桌面組件。
我們正在與一些ISV合作，他們希望其應(yīng)用程序在Windows ARM64上可用。如果符合您的情況，請通過[email protected]與我們聯(lián)系。我們希望盡快為您提供構(gòu)建版本。

Event pipe profiler APIs

事件管道是在.NET Core 2.2中添加的新子系統(tǒng)和API，可以在任何操作系統(tǒng)上執(zhí)行性能和其他診斷調(diào)查。在.NET 5.0中，事件管道已得到擴展，以使事件探查器能夠?qū)懭胧录艿朗录τ谝郧耙揽縀TW監(jiān)視應(yīng)用程序行為和性能的分析探查器，此方案至關(guān)重要。

Native exports

您現(xiàn)在可以將托管方法導(dǎo)出到本機代碼。該功能的構(gòu)建塊是托管對UnmanagedCallersOnlyAttribute的API支持。

開發(fā)團隊的Aaron Robinson一直在從事.NET Native Exports項目，該項目為將.NET組件作為本機庫發(fā)布提供了更完整的體驗。我們正在尋求有關(guān)此功能的反饋，以幫助決定是否在更高版本中將該方法包括在產(chǎn)品中。

有一些現(xiàn)有的項目可以實現(xiàn)類似的場景，例如:

• Unmanaged Exports

• DllExport
  

Application deployment

編寫或更新應(yīng)用程序后，您需要對其進行部署以供用戶利用。在此版本中，我們專注于單個文件應(yīng)用程序，并改進了.NET Core的ClickOnce。

Single file applications

單個文件應(yīng)用程序作為單個文件發(fā)布和部署。該應(yīng)用程序及其依賴項都包含在該文件中。當應(yīng)用程序運行時，依賴項直接從該文件加載到內(nèi)存中。這種方法不會降低性能。當與程序集修剪和提前編譯結(jié)合使用時，單個文件應(yīng)用程序?qū)⒆兊酶。瑔铀俣雀臁?br style="max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;">在.NET 5.0中，單個文件應(yīng)用程序主要集中在Linux上（稍后會詳細介紹）。它們可以是框架相關(guān)的，也可以是獨立的。依賴于全局安裝的.NET運行時，依賴于框架的單個文件應(yīng)用程序可能很小。自包含的單文件應(yīng)用程序更大（由于帶有運行時），但是不需要作為安裝前步驟就安裝.NET運行時，因此可以正常工作。通常，依賴框架對開發(fā)和企業(yè)環(huán)境有利，而對于ISV，獨立包含通常是更好的選擇。
我們使用.NET Core 3.1制作了一個單文件應(yīng)用程序版本。它將二進制文件打包到一個文件中以進行部署，然后將這些文件解壓縮到一個臨時目錄中以加載并執(zhí)行它們。在某些情況下，這種方法可能會更好，但是我們希望我們?yōu)?.0構(gòu)建的解決方案將是首選，并且會受到歡迎。
創(chuàng)建真正的單文件解決方案需要克服多個障礙。我們必須創(chuàng)建一個更復(fù)雜的應(yīng)用程序捆綁器，教導(dǎo)運行時從二進制資源中加載程序集，并使調(diào)試器與內(nèi)存映射的程序集兼容。我們還遇到了一些我們無法清除的障礙。

在所有平臺上，我們都有一個名為“ apphost”的組件。這是成為可執(zhí)行文件的文件，例如Windows上的?myapp.exe?或基于Unix平臺上的?./myapp?。對于單文件應(yīng)用程序，我們創(chuàng)建了一個新主機，稱為“超級主機”。它具有與常規(guī)apphost相同的角色，但還包含運行時的靜態(tài)鏈接副本。超級主機是我們單文件方法的基本設(shè)計要點。此模型是我們在Linux上使用的模型。由于各種操作系統(tǒng)限制，我們無法在Windows或macOS上實現(xiàn)此方法。在Windows或macOS上沒有超級主機。在這些操作系統(tǒng)上，本機運行時二進制文件（約3個）位于單個文件應(yīng)用程序旁邊。我們將在.NET 6.0中重新審視這種情況，但是，我們希望遇到的問題仍然具有挑戰(zhàn)性。

您可以使用以下命令生成單文件應(yīng)用程序。

• 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

您還可以使用項目文件配置單個文件發(fā)布。

"Microsoft.NET.Sdk">
  
    Exe
    net5.0
    
    true
    
    true
    
    linux-x64
    
    true
    
    true
  

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?embed?property.

我們在以前的預(yù)覽文章中看到了很多評論，詢問有關(guān)單個文件應(yīng)用程序與提前（AOT）編譯之間的關(guān)系。AOT是一個頻譜。dotnet發(fā)布生成的現(xiàn)成代碼（將?PublishReadyToRun?設(shè)置為true時）是AOT的示例。當您發(fā)布準備運行的映像時，該構(gòu)建會提前為您生成機器代碼，而不是在運行時由JIT生成。大多數(shù)人可能會將其作為AOT的定義。但是，許多人說AOT時的意思更具體。他們想要一種具有以下特征的解決方案：啟動速度極快，不存在IL（出于大小和混淆的原因），（最多）JIT是可選的，并且二進制大小盡可能小。我們使用術(shù)語“本機AOT”來描述AOT頻譜上的該點。.NET 5.0中提供的單個文件解決方案不滿足AOT的這一定義。這是一大進步，但不是“本地AOT”。我們最近發(fā)布了有關(guān)本機AOT的調(diào)查，以獲取有關(guān)該模式的更多反饋。我們正在仔細研究結(jié)果，并將其納入我們的6.0計劃工作中。

Reducing the size of container images

我們一直在尋找使.NET容器映像更小且更易于使用的機會。我們將SDK映像重新建立在ASP.NET映像之上，而不是buildpack-deps上，以顯著減小您在多階段構(gòu)建方案中提取的聚合映像的大小

對于多階段構(gòu)建，此更改具有以下優(yōu)勢（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.


此更改有助于多階段構(gòu)建，其中目標的sdk和aspnet或運行時映像是同一版本（我們希望這是常見的情況）。進行此更改后，aspnet pull（例如）將變?yōu)闊o操作狀態(tài)，因為您將通過初始sdk pull來拉伸aspnet層。
我們對Alpine和Nano Server進行了類似的更改。對于Alpine或Nano Server，沒有?buildpack-deps?映像。但是，Alpine和Nano Server的sdk映像以前未在ASP.NET映像之上構(gòu)建。我們解決了。對于多階段構(gòu)建，您將看到Alpine和Nano Server以及5.0的巨大成功。

ClickOnce Support

幾個月前，我們宣布將為.NET Core提供ClickOnce支持。該項目仍在進行中。我們希望將其作為RC2的一部分提供。我只是想分享一下我們?nèi)栽趶氖麓隧椖俊?br style="max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;">

Closing

在發(fā)行版中，“關(guān)閉”是一個有趣的章節(jié)標題。該發(fā)布確實即將結(jié)束。該團隊致力于解決所有剩余的5.0問題，并在發(fā)行版中獲得最終的錯誤修復(fù)和改進。甚至5.0 Runtime Epics問題也已解決。
我們正在研究一些深入的帖子，我們計劃在有關(guān)各種主題的最終版本發(fā)布之前發(fā)布這些帖子。注意那些。您還可以期望最終版本的發(fā)布時間更長，涵蓋更廣泛的改進和功能。
感謝您對本發(fā)行版的所有支持以及所做的所有貢獻。