【翻譯】.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問題也已解決。咱們正在研究一些深刻的帖子，咱們計劃在有關各類主題的最終版本發佈以前發佈這些帖子。 注意那些。 您還能夠指望最終版本的發佈時間更長，涵蓋更普遍的改進和功能。感謝您對本發行版的全部支持以及所作的全部貢獻。