天天看點
傳回

深度探秘.NET 5.0

今年11月10号 .NET 5.0 如約而至。這是.NET All in one後的第一個版本，雖然不是LTS(Long term support)版本，但是是生産環境可用的。

微軟從.NET 5 Preview 1就開始在自己的網站上使用.NET 5 (Bing.com、dot.net已更新并運作了數個月)，同時早期的.NET Core版本可以直接更新到.NET 5. 

有着微軟的背書，是以大家是可以放心使用的。

接下來，我們深入了解一下.NET 5.0這次帶來了哪些新的特性。

一、.NET 5.0 的一些亮點(Highlights)

1. 通過線上（生産環境）測試（battle-tested) : .NET5.0 通過在Bing.com和dot.net 托管運作數個月，全面通過了線上驗證，這證明這個版本是生産可用的

2. 性能大幅提升：GC、JIT、正規表達式、多線程和異步處理、集合、LINQ、網絡通路、JSON序列化、gRPC等等，了解詳細可以通路

    • Performance Improvements in .NET 5.0
    • Arm64 Performance in .NET 5.0
    • gRPC.

3. C# 9和F# 9 的語言提升：例如C＃9的頂級程式和記錄record，F＃5提供了互動式程式設計，并提高了.NET的性能。

4. .NET庫增強了Json序列化，正規表達式和HTTP（HTTP 1.1，HTTP / 2）的性能。這一點在第二條中已經有所涉及。

5. P95 的延遲有所減少，得益于GC、分層編譯和其他元件的一些改進

6.更好、更靈活的應用部署選項：ClickOnce用戶端應用程式釋出，單檔案應用程式，減小的容器映像大小以及添加的Server Core容器映像。

7.平台支援的範圍進一步擴充：Windows Arm64和WebAssembly

 二、再看統一平台的願景

   2019年5月6号，微軟釋出了.NET 5.0 統一平台的願景：将來隻會有一個.NET，您将可以使用它來定位Windows，Linux，macOS，iOS，Android，tvOS，watchOS和WebAssembly等。

深度探秘.NET 5.0

   實作這一願景的第一步是整合.NET倉庫，即：整合關鍵的.NET代碼庫， 這是為.NET運作庫和庫提供一個存儲庫是在各處傳遞相同産品的前提。Blazor就是代碼合并和.NET統一的最佳示例：Blazor WebAssembly的運作時和庫現在是從合并的dotnet /運作時倉庫中建構的。這意味着伺服器上的Blazor WebAssembly和Blazor使用與完全相同的代碼List<T>。

   代碼整合後，.NET Framework怎麼辦？

   .NET Framework仍然是受支援的Microsoft産品，并且每個新版本的Windows都将繼續支援.NET Framework。去年，微軟宣布已停止向.NET Framework添加新功能，逐漸向.NET Core添加更多的.NET Framework API。

   這就意味着，.NET Framework已經停更了，版本目前停留在.NET Framework 4.8. 

   這也是沒辦法的事情，統一後的.NET, 從.NET5.0開始疊代了。這次.NET 5.0的Release清單也能發現這個情況：

深度探秘.NET 5.0

    在上述情況下，目前是将.NET Framework更新到.NET Core的最佳時機了。如果比較在意LTS版本，也可以等到明年.NET 6統一更新。對于此，微軟的建議是：

    對于.NET Framework用戶端開發人員，.NET 5.0支援Windows窗體和WPF。

    對于.NET Framework伺服器開發人員， 如果采用ASP.NET Core才能使用.NET 5.0。

    對于Web Forms開發人員，Blazor通過高效且更加現代的實作方式提供類似的開發人員體驗。

    對于WCF伺服器和Workflow使用者可以檢視支援這些架構的社群項目。

    以上，對于統一後的.NET 5.0, 廣大.NET Developers 可以放心、開心地去擁抱這次更新和統一，這代表了.NET的未來。

 三、深入了解一下程式設計語言層面的提升（C# 9 和 F# 5）

   C#9和F#5是.NET 5.0版本的一部分，被包含在.NET 5.0 SDK中。接下來詳細看一下C# 9 的一些語言新特性（F# 5用的比較少，不再做詳細介紹）：

  1. Top-level programs 頂級程式

   大家會問這是什麼？這是在頂級編寫程式的一種更簡單的方式：一個更簡單的 Program.cs 檔案。

   我們知道，原先在Program類中，必須有Main函數，這是程式的一個EntryPoint入口。

using System;

namespace NET5Demo
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

   .NET 5引入Top-level programs 後，我們不需要寫Main函數了。可以直接這麼寫：

System.Console.WriteLine("Hello World!");

 大家會有疑問，真的沒有Main函數了嗎？其實這是個文法糖，我們通過IL Spy看一下反編譯後的代碼：

深度探秘.NET 5.0

  2. 邏輯模式和屬性模式比對(Logical and property patterns)

  我們可以使用not or and 實作更強的更靈活的邏輯模式比對：

  先看一個邏輯比對的Demo：

var input = Console.ReadKey();
if (input.KeyChar is 'Y' or 'y')
{
    Console.WriteLine("You choosed yes!");
}

  再看一個Switch的Demo：

int score = 90;
switch (score)
{
    case 0:
        Console.WriteLine("0分.");
        break;
    case > 0 and <= 60:
        Console.WriteLine("合格.");
        break;
    case > 60 and <= 80:
        Console.WriteLine("優秀.");
        break;
    case > 80 and <= 100:
        Console.WriteLine("卓越.");
        break;
}

 屬性模式比對：通過兩個{}，實作對對象屬性的模式比對。

Type type = Type.GetType("System.String");
if (type is not null and { FullName: "System.String" })
{
    Console.WriteLine("It's type is System.String.");
}

  3. record類型

  record是一個新增的引用類型，與class很像，那麼大家會問？為什麼增加一個record類型呢？它的使用場景是什麼呢？

  答案：為了友善比較資料是否一緻。我們寫個代碼示意一下：

  假設我們有個User類，包含ID、Name、Gender、Tel幾個屬性，如果我們要對比2個User對象是否相等，我們可能需要逐個屬性對比，或重寫Equals、GetHashCode方法。

  那麼如果我們用record類型呢？

record User(int Id, string Name, int Gender, string Tel);

 做個對象對比的Demo：

var userA = new User(1, "小米", 1, "123456789");

var userB = new User(1, "小米", 1, "123456789");

if (userA == userB)
{
    Console.WriteLine("這是一個使用者.");
}

 總結一下：record類型讓開發省去了重寫相等比較的業務邏輯，同時簡化了類型定義和初始化。

 4. 可空注解的增加和改進

  目前.NET library 類庫，已經全面設定了是否可空注解。其實這個特性其實在C# 8.0已經引入：C#8.0 引入了“可為空引用類型”和“不可為空引用類型”，使你能夠對引用類型變量的屬性作出重要聲明 ：

  #nullable enable

  class A{ }

  即.NET 5.0的類庫中已經全面更新了這個注解，友善開發時進行檢視。

  同時，這次引入新的成員是否為空的注解：MemberNotNull 和 MemberNotNullWhen，例如以下的代碼：

class UserManager
{
    User user = new User(1, "小米", 1, "123456789");

    [MemberNotNull(nameof(user))]
    public string GetUserName(string id)
    {
        return user.Name;
    }
}

  編譯器會智能提示：CS8602警告

深度探秘.NET 5.0

 四、工具類的新變化

  .NET 5.0 改進了Windows窗體設計器，更改了目标架構适用于.NET 5.0及更高版本的方式，更改了WinRT的支援方式，以及其他的一些改進。

  1. Windows窗體設計器：winform設計器

   Windows Forms設計器（用于.NET Core 3.1和.NET 5.0）已經在Visual Studio 16.8中進行了更新，現在支援所有Windows Forms控件。它還支援WinForms控件的Telerik UI。設計器包括您期望的所有設計器功能，包括：拖放，選擇，移動和調整大小，剪切/複制/粘貼/删除控件，與屬性視窗內建，事件生成等。資料綁定和對更廣泛的第三方控件的支援即将推出。

深度探秘.NET 5.0

   2. .NET 5.0目标架構

   新增一個Console類型工程後，選擇目标架構是.NET 5.0, 其Project檔案内容是這樣的：

深度探秘.NET 5.0

   新增一個Windows窗體應用工程後，選擇目标架構是.NET 5.0, 其Project檔案内容是這樣的：

深度探秘.NET 5.0

   Windows桌面API（包括Windows窗體，WPF和WinRT）僅在定位時可用net5.0-windows。同時也可以指定作業系統版本，例如net5.0-windows7或net5.0-windows10.0.17763.0（對于Windows October 2018 Update）。

   如果要使用WinRT API，則需要定位Windows 10版本。

   總結一下：

  • net5.0 是.NET 5.0的新目标架構綽号，Target Framework Moniker（TFM）。
  • net5.0結合并替換netcoreapp和netstandard TFM。
  • net5.0支援.NET Framework相容模式
  • net5.0-windows 将用于公開Windows特定功能，包括Windows窗體，WPF和WinRT API。
  • .NET 6.0将使用相同的方法，并帶有net6.0和将添加net6.0-ios和net6.0-android。
  • 特定于作業系統的TFM可以包含作業系統版本号，例如net6.0-ios14。
  • 可移植的API（如ASP.NET Core）可與一起使用net5.0。帶有的Xamarin形式也是如此net6.0。

  3. WinRT Interop的重大改進

   在以Windows API為目标這一主題上，微軟已經移至一個新模型，以作為.NET 5.0的一部分來支援WinRT API。這包括調用API（在任一方向上； CLR <==> WinRT），兩個類型系統之間的資料封送處理以及打算在類型系統或ABI邊界上統一對待的類型的統一（即“投影類型” ”，IEnumerable<T>并且IIterable<T>是示例）。

   從.NET 5.0開始，原有的WinRT互操作體系已被移除。這是一個巨大的變化。這意味着使用WinRT和.NET Core 3.x的應用程式和庫需要重新開發對接，并且不能按原樣在.NET 5.0上運作。

   使用WinRT API的庫将需要多目标來管理.NET Core 3.1和.NET 5.0之間的這種差異。

   未來，.NET 将依靠Windows中的WinRT團隊提供的新CsWinRT工具。它生成基于C＃的WinRT互操作程式集，可以通過NuGet傳遞該程式集。Windows團隊正是針對Windows中的WinRT API所做的。希望将WinRT（在Windows上）用作互作業系統的任何人都可以使用該工具，以将本機API公開給.NET或将.NET API公開給本機代碼。

   關于CsWinRT工具，已經釋出了1.0版本，具體可以參考連結：https://blogs.windows.com/windowsdeveloper/2020/11/10/announcing-c-winrt-version-1-0-with-the-net-5-ga-release/

   4. .NET Native Export/ .NET 本地導出

    即本機二進制檔案啟用導出功能。

   .NET 開發團隊的Aaron Robinson一直在從事.NET Native Exports項目，該項目為将.NET元件作為本機庫釋出提供了更完整的體驗。

   .NET Native導出項目能夠實作：

  • 公開自定義的本地出口。
  • 不需要像COM這樣的進階互操作技術。
  • 跨平台工作

   類似的實作技術，還有：

  • Unmanaged Exports
  • DllExport

   5. 事件管道

   事件管道是在.NET Core 2.2中添加的新子系統和API，可以在任何作業系統上執行性能和其他診斷調查。

   在.NET 5.0中，事件管道已得到擴充，以使事件探查器能夠寫入事件管道事件。

   對于以前依靠ETW（在Windows上）監視應用程式行為和性能的分析探查器，來說是一個很好的方案和選擇。

   這裡不做詳細展開了。

   6. 轉儲調試，Dump分析調試

   調試托管代碼需要了解托管對象和構造。資料通路元件（DAC）是運作時執行引擎的子集，該引擎具有這些構造的知識，并且可以在沒有運作時的情況下通路這些托管對象。

   現在，可以使用WinDBG或Windows在Windows上分析在Linux上收集的.NET Core程序轉儲dotnet dump analyze。

   本次釋出還增加了對從macOS上運作的.NET程序捕獲ELF轉儲的支援。由于ELF不是lldbmacOS上的本機可執行檔案（像這樣的本地調試器将無法與這些轉儲一起使用）檔案格式，是以我們将其設為啟用功能。

   要在macOS上支援轉儲收集，請設定環境變量COMPlus_DbgEnableElfDumpOnMacOS=1。可以使用來分析産生的轉儲dotnet dump analyze。

   7. 列印環境資訊

   随着.NET擴充了對新作業系統和晶片體系結構的支援，有時需要一種列印環境資訊的方法。.NET 5.0 建立了一個簡單的.NET工具來執行此操作，稱為dotnet-runtimeinfo。可以使用以下指令安裝和運作該工具:

dotnet tool install -g dotnet-runtimeinfo
dotnet-runtimeinfo
深度探秘.NET 5.0

   五、運作時和類庫的提升

    1. RyuJIT的代碼品質提升

    可以參考這個連結：Performance Improvements in RyuJIT in .NET Core and .NET Framework

    2. GC垃圾回收

  • Card mark stealing – dotnet/coreclr #25986  Server GC (on different threads) can now work-steal while marking gen0/1 objects held live by older generation objects. This means that ephemeral GC pauses are shorter for scenarios where some GC threads took much longer to mark than others.  ServerGC 中标記階段的耗時更短了
  • Introducing Pinned Object Heap – dotnet/runtime #32283 — Adds the Pinned Object Heap (POH). This new heap (a peer to the Large Object Heap (LOH)) will allow the GC to manage pinned objects separately, and as a result avoid the negative effects of pinned objects on the generational heaps. 新增固定對象堆（POH）。此新堆（與大對象堆（LOH）對等）将允許GC單獨管理固定對象，進而避免固定對象對堆的負面影響。
  • Allow allocating large object from free list while background sweeping SOH — Enabled LOH allocations using the free list while BGC is sweeping SOH. Previously this was only using end of segment space on LOH. This allowed for better heap usage.允許在背景掃描SOH時從空閑清單中配置設定大對象
  • Background GC suspension fixes – dotnet/coreclr #27729 — Suspension fixes to reduce time for both BGC and user threads to be suspended. This reduces the total time it takes to suspend managed threads before a GC can happen. dotnet/coreclr #27578 also contributes to the same outcome. 挂起修複程式可減少BGC和使用者線程挂起的時間。這樣可以減少發生GC之前挂起托管線程所需的總時間。
  • Fix named cgroup handling in docker — Added support to read limits from named cgroups. Previously we only read from the global one. 修複了docker中命名cgroup處理的問題—添加了對從命名cgroups讀取限制的支援
  • Optimize vectorized sorting – dotnet/runtime #37159 — vectorized mark list sorting in GC which reduces the ephemeral GC pause time (also dotnet/runtime #40613). GC中的矢量化标記清單排序，減少了短暫的GC暫停時間
  • Generational aware analysis – dotnet/runtime #40322 — generational aware analysis that allows you to determine what old generation objects hold on to younger generation objects thus making them survive and contribute to ephemeral GC pause time.GC代感覺分析，能夠确定哪些舊世代對象保留在年輕代對象上，進而使它們得以生存并有助于短暫的GC暫停時間。
  • Optimize decommitting GC heap memory pages – dotnet/runtime #35896 — optimized decommit, much better decommit logic and for Server GC took decommit completely out of the “stop the world” phase which reduced blocking GC pause time.優化了取消授權，更好的取消授權邏輯，對于Server GC，完全取消了“停止一切”階段的授權，進而減少了阻塞GC的暫停時間

     整體總結一下，Server GC延遲更低了，CPU消耗更少、性能更好了。

     3. Windows Arm64的支援

     .NET應用程式現在可以在Windows Arm64上本機運作。在.NET Core 3.0中添加的對Linux Arm64的支援（對glibc和musl的支援）。使用.NET 5.0，可以在Windows Arm64裝置（例如Surface Pro X）上開發和運作應用程式。也可以通過x86仿真在Windows Arm64上運作.NET Core和.NET Framework應用程式。但是本機運作Arm64具有更好的性能。

     同時，.NET 5.0 SDK目前在Windows Arm64上不包含Windows桌面元件-Windows窗體和WPF。Windows Arm64上支援SDK，控制台和ASP.NET Core應用程式，但Windows桌面元件不支援。

     4. Arm64性能優化

     .NET 5.0 中主要針對Arm64平台做了以下優化：

  • 調整Arm64的JIT優化（示例）
  • 啟用并利用Arm64硬體内部函數（示例）。
  • 調整Arm64庫中對性能至關重要的算法（示例）。

     更多詳細資訊，請參見在.NET 5.0中提高Arm64性能。

      5. P95 +延遲改進

      Stack Overflow的一位工程師Nick Craver最近分享了他們更新.NET Core後，對延遲的改進：

      問題頁面的展現時間中值從大約21毫秒（由于GC而有所增加）降至約15毫秒。

      第95個百分位數從〜40ms下降到〜30ms（相同測量）。第99位從〜60ms降至〜45ms。

      .NET項目組的解讀是這樣的：固定對象一直是GC性能的長期挑戰，因為它們會加速（或導緻）記憶體碎片。.NET 5.0為固定對象添加了新的GC堆。該固定對象堆是基于這樣的假設（以空間換時間），他們的存在會導緻不相稱的性能挑戰極少數固定的對象。将固定的對象（尤其是由.NET庫作為實作細節建立的對象）移動到唯一的區域是有意義的，而垃圾回收代的GC堆幾乎沒有或沒有固定的對象，是以具有更高的性能。

       6. 分層編譯性能改進

       關于分層編譯，大家可以參考這個連接配接：https://devblogs.microsoft.com/dotnet/tiered-compilation-preview-in-net-core-2-1

       在.NET 5.0中對分層編譯進行了兩項重大改進。下面這2段有點複雜，也比較晦澀

      分層編譯的主要機制是調用計數。一旦某個方法被調用了n次，運作時就會要求JIT以更高的品質重新編譯該方法。從最早的性能分析中，發現采用計數機制太慢，但是沒有找到解決該問題的直接方法。.NET 5.0中改進了分層JIT編譯所使用的調用計數機制，以平滑啟動期間的性能。在過去的發行版中，已經發現在程序生命周期的前10到15秒鐘内，性能會發生不可預測的變化（主要是針對Web伺服器）。目前應該已經解決了。

     另一個性能挑戰是對具有循環的方法使用分層編譯。根本的問題是，您可以使用帶有循環多次的循環的冷方法（僅調用一次或幾次； $ lt; n）。我們稱這種病理情況為“冷方法”。熱循環”。可以想象Main應用程式的方法會發生這種情況。結果，預設情況下，我們禁用了帶循環方法的分層編譯。相反，使應用程式可以選擇使用帶循環的分層編譯。在某些情況下看到了個位數的高性能改進後，PowerShell就是選擇執行此操作的應用程式。

     為了更好地解決循環問題，.NET 實作了棧上替換（OSR）。這類似于Java虛拟機具有的同名功能。OSR允許在方法執行過程中重新編譯目前正在運作的方法執行的代碼，而這些方法是“堆棧上”活動的。該功能目前處于試驗和選擇啟用狀态，并且僅在x64上可用。

     要使用OSR，必須啟用多個功能。目前.NET 5.0中沒有啟用OSR，這個功能尚未決定在生産環境中是否啟用，是以這個技術點，了解即可。

      7. JSON序列化 System.Text.Json

      .NET 5.0 對System.Text.Json進行了顯着改進，以提高性能和可靠性，同時API盡可能地和Newtonsoft.Json類似。它還包括對将JSON對象反序列化對record類型的支援。

      同時微軟提供了System.Text.Json替換Newtonsoft.Json的遷移指南。該指南詳細闡明了這兩個API之間的關系。

      如何從 Newtonsoft.Json 遷移到 System.Text.Json

JsonSerializer

.NET 5.0中的性能顯着提高。Stephen Toub在.NET 5中的性能改進中介紹了一些

JsonSerializer

改進。

  六、應用程式部署

    應用程式開發完成後，根據實際的需要，可能會部署到Web伺服器，雲服務或用戶端計算機，或者使用Azure DevOps或GitHub Actions之類的服務進行CI/CD。

    .NET 5.0專注于改善單個檔案應用程式，減小docker多階段建構的容器大小，并為使用.NET Core部署ClickOnce應用程式提供更好的支援。

    1. 容器

    與容器的互動協作非常重要。這個版本中添加了OpenTelemetry支援，可以從應用程式中捕獲分布式跟蹤和名額。dotnet-monitor是一個新工具，可以作為從.NET程序通路診斷資訊的主要工具。特别是，我們已經開始建構dotnet-monitor的容器變體，您可以将其用作應用程式sidecar。同時，.NET項目組正在建構dotnet / tye，以提高微服務開發人員在開發和部署到Kubernetes環境中的效率。

   .NET運作時現在支援cgroup v2，這個API預計将在2020年以後成為與容器相關的重要API。Docker目前使用cgroup v1（.NET已支援）。相比之下，cgroup v2比cgroup v1更簡單，更有效且更安全。.NET 5.0将在cgroup v2環境中正常工作。

   除了Nano Server，微軟還将釋出Windows Server Core映像，努力減小Windows Server Core映像的大小。

    更小的體積、更低的成本、更快的啟動性能。.NET 5.0中将SDK映像重建立立在ASP.NET映像之上，而不是buildpack-deps，這樣可以顯着減小在多階段建構方案中提取的聚合映像的大小。

深度探秘.NET 5.0

    2. 單檔案應用    

    單個檔案應用程式作為單個檔案釋出和部署。該應用程式及其依賴項都包含在該檔案中。當應用程式運作時，依賴項直接從該檔案加載到記憶體中（不影響性能）。

    在.NET 5.0中，單個檔案應用程式主要集中在Linux上。它們可以是架構相關的，也可以是獨立的。依賴于全局安裝的.NET運作時，依賴于架構的單個檔案應用程式可能很小。自包含的單檔案應用程式較大（由于帶有運作時），但不需要作為安裝前步驟就安裝.NET運作時，是以可以正常工作。通常，依賴架構對開發和企業環境有利，而對于ISV，獨立包含通常是更好的選擇。

    .NET Core 3.1制作了一個單檔案應用程式版本。它将二進制檔案打包到一個檔案中以進行部署，然後将這些檔案解壓縮到一個臨時目錄中以加載并執行它們。在某些情況下，這種方法會更好，但是希望為5.0建構的解決方案将是首選，并且會受到歡迎。  

    可以使用以下指令來生成單檔案應用程式：

架構相關的單檔案應用程式：
dotnet publish -r linux-x64 --self-contained false /p:PublishSingleFile=true
自包含的單檔案應用程式：
dotnet publish -r linux-x64 --self-contained true /p:PublishSingleFile=true

　 3. ClickOnce

    ClickOnce一直是流行的.NET部署選項，曆史也比較悠久了。.NET Core 3.1和.NET 5.0 Windows應用程式現在支援它。   

     以上是.NET 5.0 釋出後的技術梳理和整理，.NET 5.0作為.NET技術棧上近幾年一個重量級的裡程碑，是All in one，統一平台的第一個版本。現在有微軟的背書，微軟從.NET Preview 1就開始在自己的網站上運作.NET 5, (Bing.com、dot.net已更新并運作了數個月)，同時早期的.NET Core版本可以直接更新到.NET 5. 是以大家可以放心使用的。也推薦大家逐漸遷移更新到.NET 5.0.

    參考連結：

   https://devblogs.microsoft.com/dotnet/announcing-net-5-0?WT.mc_id=DT-MVP-5003918

   https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/#json?WT.mc_id=DT-MVP-5003918

   https://blogs.windows.com/windowsdeveloper/2020/11/10/announcing-c-winrt-version-1-0-with-the-net-5-ga-release?WT.mc_id=DT-MVP-5003918

周國慶

2020/11/15

c# .net core
上一篇: 基于Azure IoT開發.NET物聯網應用系列-全新的Azure IoT架構
下一篇: 如何寫好、管好單元測試？基于Roslyn+CI分析單元測試，嚴控産品提測品質

繼續閱讀