【翻譯】.NET 5 Preview8發佈

2020 年 8 月 26 日
筆記
.NET, .NET 5, .NET Core, AspNet Core

【翻譯】.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:

今天同時也發佈了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.

.NET 5.0還包括使用Mono運行時和.NET庫對Web程序集的支持。這是.NET 5.0中Blazor Web程序集的基礎。這是對Blazor 3.2的更改，後者使用了Mono運行時庫和Mono庫。去年，我們提出了一個統一的.NET平台的願景，該平台具有適用於所有.NET應用程序類型的一組庫和工具。此項更改的好處是，可以享受.NET的單一開發經驗，可以在各種.NET應用類型之間實現更高的兼容性，並且僅維護和改進一個代碼庫。我們使用Web程序集進行的更改（使用.NET庫）是對該願景的首付。我們期望通過.NET 6.0實現其餘的願景，主要集中在Xamarin（iOS和Android）上。
.NET 5.0 還包括使用Mono運行時和.NET庫對Web程序集的支持，這是.NET 5.0中Blazor Web程序集的基礎。這是對Blazor 3.2的更改，後者使用了Mono運行時和Mono庫，在去年他們提出了一個統一的.NET平台的願景，該平台具有適用於所有.NET應用程序類型的一組庫和工具，此項更改的好處是，可以享受.NET的單一開發經驗，可以在各種的.NET應用類型之間實現更高的兼容性，並且僅維護和改進一個代碼庫，在這次使用Web程序集進行的更改（使用.NET庫）是對該願景的首次交付，希望能通過.NET6.0實現其餘的願景，主要集中在Xamarin（iOS和Android）上。
現在這個版本功能開發已經完成，讓我們看一下.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](//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上可用。如果符合您的情況，請通過[email protected]與我們聯繫。我們希望儘快為您提供構建版本。

Event pipe profiler APIs

事件管道是在.NET Core 2.2中添加的新子系統和API，可以在任何操作系統上執行性能和其他診斷調查。在.NET 5.0中，事件管道已得到擴展，以使事件探查器能夠寫入事件管道事件。對於以前依靠ETW監視應用程序行為和性能的分析探查器，此方案至關重要。

Native exports

您現在可以將託管方法導出到本機代碼。該功能的構建塊是託管對UnmanagedCallersOnlyAttribute的API支持。

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

有一些現有的項目可以實現類似的場景，例如:

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問題也已解決。
我們正在研究一些深入的帖子，我們計劃在有關各種主題的最終版本發佈之前發佈這些帖子。注意那些。您還可以期望最終版本的發佈時間更長，涵蓋更廣泛的改進和功能。
感謝您對本發行版的所有支持以及所做的所有貢獻。

Tags: .NET .NET 5 .NET Core AspNet Core