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


.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](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上可用。 如果符合您的情況，請通過[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元件作為本機庫釋出提供了更完整的體驗。 我們正在尋求有關此功能的反饋，以幫助決定是否在更高版本中將該方法包括在產品中。

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

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