.NET 6 攻略大全（一）
點擊上方藍字
關注我們
（本文閱讀時間：15分鐘)
歡迎使用 .NET 6。今天的版本是.NET 團隊和社區一年多努力的結果。C# 10 和 F# 6 提供了語言改進，使您的代碼更簡單、更好、性能大幅提升，我們已經看到微軟降低了托管云服務的成本。.NET 6 是第一個原生支持 Apple Silicon (Arm64) 的版本，并且還針對 Windows Arm64 進行了改進。我們構建了一個新的動態配置文件引導優化 (PGO) 系統，該系統可提供僅在運行時才可能進行的深度優化。使用dotnet monitor 和 OpenTelemetry 改進了云診斷。WebAssembly 支持更有能力和性能。為HTTP/3添加了新的 API ，處理 JSON、數學和直接操作內存。.NET 6 將支持三年。開發人員已經開始將應用程序升級到 .NET 6，我們在生產中聽到了很好的早期成果。.NET 6 已為您的應用程序做好準備。
您可以下載適用于 Linux、macOS 和 Windows 的.NET 6 。
安裝程序和二進制文件
容器圖像
Linux 軟件包
發行說明
API 差異
已知的問題
GitHub 問題跟蹤器
請參閱 ASP.NET Core、Entity Framework、Windows Forms、.NET MAUI、YARP 和 dotnet 監視器帖子，了解各種場景中的新增功能。
.NET 6?下載
https://dotnet.microsoft.com/zh-cn/download/dotnet/6.0
.NET 6 亮點?
.NET 6 是
使用 Microsoft 服務、其他公司運行的云應用程序和開源項目進行生產壓力測試。
作為最新的長期支持 (LTS) 版本支持三年。
跨瀏覽器、云、桌面、物聯網和移動應用程序的統一平臺，所有這些都使用相同的 .NET 庫并能夠輕松共享代碼。
性能得到了極大的提高，尤其是文件 I/O，這共同導致了執行時間、延遲和內存使用的減少。
C# 10 提供了語言改進，例如記錄結構、隱式使用和新的 lambda 功能，而編譯器添加了增量源生成器。F# 6添加了新功能，包括基于任務的異步、管道調試和眾多性能改進。
Visual Basic 在 Visual Studio 體驗和 Windows 窗體項目打開體驗方面有所改進。
Hot Reload 使您能夠跳過重新構建和重新啟動您的應用程序以查看新更改（在您的應用程序運行時），Visual Studio 2022 和 .NET CLI 支持 C# 和 Visual Basic。
云診斷已通過 OpenTelemetry 和 dotnet monitor 得到改進，現在在生產中支持并在 Azure 應用服務中可用。
JSON API 的功能更強大，并且通過序列化程序的源生成器具有更高的性能。
ASP.NET Core 中引入的最小 API 可簡化入門體驗并提高 HTTP 服務的性能。
Blazor 組件現在可以從 JavaScript 呈現并與現有的基于 JavaScript 的應用程序集成。
Blazor WebAssembly (Wasm) 應用程序的 WebAssembly AOT編譯，以及對運行時重新鏈接和本機依賴項的支持。
使用 ASP.NET Core 構建的單頁應用程序現在使用更靈活的模式，可與 Angular、React 和其他流行的前端 JavaScript 框架一起使用。
添加了 HTTP/3，以便 ASP.NET Core、HttpClient 和 gRPC 都可以與 HTTP/3 客戶端和服務器交互。
File IO 現在支持符號鏈接，并且通過 re-written-from-scratch 大大提高了性能FileStream。
通過支持 OpenSSL 3、ChaCha20Poly1305 加密方案和運行時深度防御緩解，特別是 W^X和CET，安全性得到了改進。
可以為 Linux、macOS 和 Windows（以前只有 Linux）發布單文件應用程序（免提取）。
IL 修整現在更加強大和有效，新的警告和分析器可確保正確的最終結果。
添加了源生成器和分析器，可幫助您生成更好、更安全和更高性能的代碼。
源代碼構建使 Red Hat 等組織能夠從源代碼構建 .NET 并向其用戶提供自己的構建。
該版本包括大約一萬次 git 提交。即使這篇文章很長，它也跳過了許多改進。您必須下載并試用.NET 6 才能看到所有新功能。
支持
.NET 6 是一個長期支持 (LTS) 版本，將支持三年。它支持多種操作系統，包括 macOS Apple Silicon 和 Windows Arm64。
Red Hat 與 .NET 團隊合作，在 Red Hat Enterprise Linux 上支持 .NET。在 RHEL 8 及更高版本上，.NET 6 將可用于 AMD 和 Intel (x64_64)、ARM (aarch64) 以及 IBM Z 和 LinuxONE (s390x) 架構。
請開始將您的應用程序遷移到 .NET 6，尤其是 .NET 5 應用程序。我們從早期采用者那里聽說，從 .NET Core 3.1 和 .NET 5 升級到 .NET 6 很簡單。
Visual Studio 2022 和 Visual Studio 2022 for Mac 支持 .NET 6 。Visual Studio 2019、Visual Studio for Mac 8 或 MSBuild 16 不支持它。如果要使用 .NET 6，則需要升級到Visual Studio 2022（現在也是 64 位）。Visual Studio Code C# 擴展支持 .NET 6 。
Azure App 服務：
Azure Functions 現在支持在 .NET 6 中運行無服務器函數。
App Service .NET 6 GA Announcement 為 ASP.NET Core 開發人員提供了信息和詳細信息，他們很高興今天開始使用 .NET 6。
Azure 靜態 Web 應用現在支持帶有 Blazor WebAssembly 前端和 Azure Function API 的全棧 .NET 6 應用程序。
注意：如果您的應用已經在應用服務上運行 .NET 6 預覽版或 RC 版本，則在將 .NET 6 運行時和 SDK 部署到您所在區域后，它將在第一次重新啟動時自動更新。如果您部署了一個獨立的應用程序，您將需要重新構建和重新部署。
統一擴展平臺
.NET 6 為瀏覽器、云、桌面、物聯網和移動應用程序提供了一個統一的平臺。底層平臺已更新，可滿足所有應用類型的需求，并便于在所有應用中重用代碼。新功能和改進同時適用于所有應用程序，因此您在云或移動設備上運行的代碼的行為方式相同并具有相同的優勢。
.NET 開發人員的范圍隨著每個版本的發布而不斷擴大。機器學習和 WebAssembly 是最近添加的兩個。例如，通過機器學習，您可以編寫在流數據中查找異常的應用程序。使用 WebAssembly，您可以在瀏覽器中托管 .NET 應用程序，就像 HTML 和 JavaScript 一樣，或者將它們與 HTML 和 JavaScript 混合使用。
最令人興奮的新增功能之一是.NET Multi-platform App UI (.NET MAUI)。您現在可以在單個項目中編寫代碼，從而跨桌面和移動操作系統提供現代客戶端應用程序體驗。.NET MAUI 將比 .NET 6 稍晚發布。我們在 .NET MAUI 上投入了大量時間和精力，很高興能夠發布它并看到 .NET MAUI 應用程序投入生產。
當然，.NET 應用程序也可以在家中使用 Windows 桌面（使用 Windows Forms 和WPF）以及使用 ASP.NET Core 在云中。它們是我們提供時間最長的應用程序類型，并且仍然非常受歡迎，我們在 .NET 6 中對其進行了改進。
面向.NET 6
繼續以廣泛平臺為主題，在所有這些操作系統上編寫 .NET 代碼很容易。
要以 .NET 6 為目標，您需要使用 .NET 6 目標框架，如下所示：
<TargetFramework>net6.0</TargetFramework>net6.0 Target Framework Moniker (TFM) 使您可以訪問 .NET 提供的所有跨平臺 API。如果您正在編寫控制臺應用程序、ASP.NET Core 應用程序或可重用的跨平臺庫，這是最佳選擇。
如果您針對特定操作系統（例如編寫Windows 窗體或 iOS 應用程序），那么還有另一組 TFM（每個都針對不言而喻的操作系統）供您使用。它們使您可以訪問所有 net6.0的API以及一堆特定于操作系統的 API。
? net6.0-android
? net6.0-ios
? net6.0-maccatalyst
? net6.0-tvos
? net6.0-windows
每個無版本 TFM 都相當于針對 .NET 6 支持的最低操作系統版本。如果您想要具體或訪問更新的 API，可以指定操作系統版本。
net6.0 和 net6.0-windows TFMs 都支持（與 .NET 5 相同）。Android 和 Apple TFM 是 .NET 6 的新功能，目前處于預覽階段。稍后的 .NET 6 更新將支持它們。
操作系統特定的 TFM 之間沒有兼容性關系。例如，net6.0-ios 與 net6.0-tvos 不兼容。如果您想共享代碼，您需要使用帶有 #if 語句的源代碼或帶有 net6.0 目標代碼的二進制文件來實現。
性能
自從我們啟動 .NET Core 項目以來，該團隊一直在不斷地關注性能。Stephen Toub 在記錄每個版本的 .NET 性能進展方面做得非常出色。歡迎查看在 .NET 6 中的性能改進的帖子。在這篇文章中，里面包括您想了解的重大性能改進，包括文件 IO、接口轉換、PGO 和 System.Text.Json。
▌動態?PGO
動態輪廓引導優化 (PGO)可以顯著提高穩態性能。例如，PGO 為 TechEmpower JSON“MVC”套件的每秒請求數提高了 26%（510K -> 640K）。
動態 PGO 建立在分層編譯的基礎上，它使方法能夠首先非常快速地編譯（稱為“第 0 層”）以提高啟動性能，然后在啟用大量優化的情況下隨后重新編譯（稱為“第 1 層”）一旦該方法被證明是有影響的。該模型使方法能夠在第 0 層中進行檢測，以允許對代碼的執行進行各種觀察。在第 1 層重新調整這些方法時，從第 0 層執行收集的信息用于更好地優化第 1 層代碼。這就是機制的本質。
動態 PGO 的啟動時間將比默認運行時稍慢，因為在第 0 層方法中運行了額外的代碼來觀察方法行為。
要啟用動態 PGO，請在應用程序將運行的環境中設置 DOTNET_TieredPGO=1。您還必須確保啟用分層編譯（默認情況下）。動態 PGO 是可選的，因為它是一種新的且有影響力的技術。我們希望發布選擇加入使用和相關反饋，以確保它經過全面壓力測試。我們對分層編譯做了同樣的事情。至少一個非常大的 Microsoft 服務支持并已在生產中使用動態 PGO。我們鼓勵您嘗試一下。
您可以在.NET 6中的性能帖子中看到更多關于動態 PGO 優勢的信息，包括以下微基準，它測量特定 LINQ 枚舉器的成本。
private IEnumerator<long> _source = Enumerable.Range(0, long.MaxValue).GetEnumerator();[Benchmark] public?void?MoveNext()?=>?_source.MoveNext();這是有和沒有動態 PGO 的結果。
| 方法 | 意思是 | 代碼大小 |
| PGO 已禁用 | 1.905 納秒 | 30乙 |
| 啟用 PGO | 0.7071 納秒 | 105乙 |
這是一個相當大的差異，但代碼大小也有所增加，這可能會讓一些讀者感到驚訝。這是由 JIT 生成的匯編代碼的大小，而不是內存分配（這是一個更常見的焦點）。.NET 6 性能帖子對此有很好的解釋。
PGO 實現中常見的一種優化是“熱/冷分離”，其中經常執行的方法部分（“熱”）在方法開始時靠近在一起，而不經常執行的方法部分（“冷”）是移到方法的末尾。這樣可以更好地使用指令緩存，并最大限度地減少可能未使用的代碼負載。
作為上下文，接口調度是 .NET 中最昂貴的調用類型。非虛擬方法調用是最快的，甚至更快的是可以通過內聯消除的調用。在這種情況下，動態 PGO 為 MoveNext 提供了兩個（替代）調用站點。第一個 - 熱的 - 是對 Enumerable+RangeIterator.MoveNext 的直接調用，另一個 - 冷的 - 是通過 IEnumerator<int> 的虛擬接口調用。如果大多數時候最熱門的人都被叫到，那將是一個巨大的勝利。
這就是魔法。當 JIT 檢測此方法的第 0 層代碼時，包括檢測此接口調度以跟蹤每次調用時 _source 的具體類型。JIT 發現每次調用都在一個名為 Enumerable+RangeIterator 的類型上，這是一個私有類，用于在 Enumerable 實現內部實現 Enumerable.Range。因此，對于第 1 層，JIT 已發出檢查以查看 _source 的類型是否為 Enumerable+RangeIterator：如果不是，則跳轉到我們之前強調的執行正常接口調度的冷部分。但如果是 - 基于分析數據，預計絕大多數時間都是這種情況 - 然后它可以繼續直接調用非虛擬化的 Enumerable+RangeIterator.MoveNext 方法。不僅如此，它還認為內聯 MoveNext 方法是有利可圖的。最終效果是生成的匯編代碼有點大，但針對預期最常見的確切場景進行了優化。當我們開始構建動態 PGO 時，這些就是我們想要的那種勝利。
動態 PGO 將在 RyuJIT 部分再次討論。
▌文件 IO 改進
FileStream 幾乎完全用 .NET 6 重寫，重點是提高異步文件 IO 性能。在 Windows 上，實現不再使用阻塞 API，并且可以快幾倍！我們還改進了所有平臺上的內存使用。在第一次異步操作（通常分配）之后，我們已經使異步操作免分配！此外，我們已經使 Windows 和 Unix 實現不同的邊緣情況的行為統一（這是可能的）。
這種重寫的性能改進使所有操作系統受益。對 Windows 的好處是最大的，因為它遠遠落后。macOS 和 Linux 用戶也應該會看到顯著 FileStream 的性能改進。
以下基準將 100 MB 寫入新文件。
private byte[] _bytes = new byte[8_000];[Benchmark] public async Task Write100MBAsync() {using FileStream fs = new("file.txt", FileMode.Create, FileAccess.Write, FileShare.None, 1, FileOptions.Asynchronous);for (int i = 0; i < 100_000_000 / 8_000; i++)await fs.WriteAsync(_bytes); }在帶有 SSD 驅動器的 Windows 上，我們觀察到4倍的加速和超過1200倍的分配下降：
| 方法 | 運行 | 意思是 | 比率 | 已分配 |
| 寫100MBAsync | .NET 5.0 | 1,308.2 毫秒 | 1.00 | 3,809 KB |
| 寫100MBAsync | .NET 6.0 | 306.8 毫秒 | 0.24 | 3 KB |
我們還認識到需要更高性能的文件 IO 功能：并發讀取和寫入，以及分散/收集 IO。針對這些情況，我們為 System.IO.File 和 System.IO.RandomAccess 類引入了新的 API。
async Task AllOrNothingAsync(string path, IReadOnlyList<ReadOnlyMemory<byte>> buffers) {using SafeFileHandle handle = File.OpenHandle(path, FileMode.Create, FileAccess.Write, FileShare.None, FileOptions.Asynchronous,preallocationSize: buffers.Sum(buffer => buffer.Length)); // hint for the OS to pre-allocate disk spaceawait RandomAccess.WriteAsync(handle, buffers, fileOffset: 0); // on Linux it's translated to a single sys-call! }該示例演示：
使用新 File.OpenHandle API 打開文件句柄。
使用新的預分配大小功能預分配磁盤空間。
使用新的 Scatter/Gather IO API寫入文件。
預分配大小功能提高了性能，因為寫入操作不需要擴展文件，并且文件不太可能被碎片化。這種方法提高了可靠性，因為寫入操作將不再因空間不足而失敗，因為空間已被保留。Scatter/Gather IO API 減少了寫入數據所需的系統調用次數。
▌更快的接口檢查和轉換
界面鑄造性能提高了 16% - 38%。這種改進對于 C# 與接口之間的模式匹配特別有用。
這張圖表展示了一個有代表性的基準測試的改進規模。
將 .NET 運行時的一部分從 C++ 遷移到托管 C# 的最大優勢之一是它降低了貢獻的障礙。這包括接口轉換，它作為早期的 .NET 6 更改移至 C#。.NET 生態系統中懂 C# 的人比懂 C++ 的人多（而且運行時使用具有挑戰性的 C++ 模式）。僅僅能夠閱讀構成運行時的一些代碼是培養以各種形式做出貢獻的信心的重要一步。
歸功于 Ben Adams。
▌System.Text.Json 源生成器
我們為 System.Text.Json 添加了一個源代碼生成器，它避免了在運行時進行反射和代碼生成的需要，并且可以在構建時生成最佳序列化代碼。序列化程序通常使用非常保守的技術編寫，因為它們必須如此。但是，如果您閱讀自己的序列化源代碼（使用序列化程序），您可以看到明顯的選擇應該是什么，可以使序列化程序在您的特定情況下更加優化。這正是這個新的源生成器所做的。
除了提高性能和減少內存之外，源代碼生成器還生成最適合裝配修整的代碼。這有助于制作更小的應用程序。
序列化POCO是一種非常常見的場景。使用新的源代碼生成器，我們觀察到序列化速度比我們的基準快 1.6 倍。
| 方法 | 意思是 | 標準差 | 比率 |
| 串行器 | 243.1 納秒 | 9.54 納秒 | 1.00 |
| SrcGenSerializer | 149.3 納秒 | 1.91 納秒 | 0.62 |
TechEmpower 緩存基準測試平臺或框架對來自數據庫的信息進行內存緩存。基準測試的 .NET 實現執行緩存數據的 JSON 序列化，以便將其作為響應發送到測試工具。
| 請求/秒 | 要求 | |
| net5.0 | 243,000 | 3,669,151 |
| 網6.0 | 260,928 | 3,939,804 |
| net6.0 + JSON 源碼生成 | 364,224 | 5,499,468 |
我們觀察到約 100K RPS 增益（增加約 40%）。與MemoryCache 性能改進相結合時，.NET 6 的吞吐量比 .NET 5 高 50% ！
C# 10
歡迎來到 C# 10。C# 10的一個主要主題是繼續從C# 9中的頂級語句開始的簡化之旅。新功能從 Program.cs 中刪除了更多的儀式，導致程序只有一行。他們的靈感來自于與沒有 C# 經驗的人（學生、專業開發人員和其他人）交談，并了解什么對他們來說最有效且最直觀。
大多數.NET SDK 模板都已更新，以提供現在可以使用 C# 10 實現的更簡單、更簡潔的體驗。我們收到反饋說，有些人不喜歡新模板，因為它們不適合專家，刪除面向對象，刪除在編寫 C# 的第一天學習的重要概念，或鼓勵在一個文件中編寫整個程序。客觀地說，這些觀點都不正確。新模型同樣適用于作為專業開發人員的學生。但是，它與 .NET 6 之前的 C 派生模型不同。
C# 10 中還有其他一些功能和改進，包括記錄結構。
▌全局使用指令
全局 using 指令讓您 using 只需指定一次指令并將其應用于您編譯的每個文件。
以下示例顯示了語法的廣度：
? global using System;
? global using static System.Console;
? global using Env = System.Environment;
您可以將global using語句放在任何 .cs 文件中，包括在 Program.cs 中。
隱式 usings 是一個 MSBuild 概念，它會根據 SDK自動添加一組指令。例如，控制臺應用程序隱式使用不同于 ASP.NET Core。
隱式使用是可選的，并在 a 中啟用 PropertyGroup：
<ImplicitUsings>enable</ImplicitUsings>隱式使用對于現有項目是可選的，但默認包含在新 C# 項目中。有關詳細信息，請參閱隱式使用。
▌文件范圍的命名空間
文件范圍的命名空間使您能夠聲明整個文件的命名空間，而無需將剩余內容嵌套在{ ... }中. 只允許一個，并且必須在聲明任何類型之前出現。
新語法是單個的一行：
namespace MyNamespace;class MyClass { ... } // Not indented這種新語法是三行縮進樣式的替代方案：
namespace MyNamespace {class MyClass { ... } // Everything is indented }好處是在整個文件位于同一個命名空間中的極其常見的情況下減少縮進。
▌記錄結構
C# 9 將記錄作為一種特殊的面向值的類形式引入。在 C# 10 中，您還可以聲明結構記錄。C# 中的結構已經具有值相等，但記錄結構添加了 == 運算符和 IEquatable<T> 的實現，以及基于值的 ToString 實現：
public record struct Person {public string FirstName { get; init; }public string LastName { get; init; } }就像記錄類一樣，記錄結構可以是“位置的”，這意味著它們有一個主構造函數，它隱式聲明與參數對應的公共成員：
但是，與記錄類不同，隱式公共成員是可變的自動實現的屬性。這樣一來，記錄結構就成為了元組的自然成長故事。例如，如果您有一個返回類型(string FirstName, string LastName)，并且您希望將其擴展為命名類型，您可以輕松地聲明相應的位置結構記錄并維護可變語義。
如果你想要一個具有只讀屬性的不可變記錄，你可以聲明整個記錄結構 readonly（就像你可以其他結構一樣）：
public readonly record struct Person(string FirstName, string LastName);C# 10 不僅支持記錄結構，還支持所有結構以及匿名類型的 with 表達式：
var updatedPerson = person with { FirstName = "Mary" }F# 6
F# 6旨在讓 F# 更簡單、更高效。這適用于語言設計、庫和工具。我們對 F# 6（及更高版本）的目標是消除語言中讓用戶感到驚訝或阻礙學習 F# 的極端情況。我們很高興能與 F# 社區合作進行這項持續的努力。
▌讓 F# 更快、更互操作
新語法task {…}直接創建一個任務并啟動它。這是 F# 6 中最重要的功能之一，它使異步任務更簡單、性能更高，并且與 C# 和其他 .NET 語言的互操作性更強。以前，創建 .NET 任務需要使用async {…}來創建任務并調用 Async.StartImmediateAsTask。
該功能 task {…}建立在稱為“可恢復代碼”RFC FS-1087的基礎之上。可恢復代碼是一個核心特性，我們希望在未來使用它來構建其他高性能異步和屈服狀態機。
F# 6 還為庫作者添加了其他性能特性，包括 InlineIfLambda 和F# 活動模式的未裝箱表示。一個特別顯著的性能改進在于列表和數組表達式的編譯，現在它們的速度提高了4 倍，并且調試也更好、更簡單。
▌讓 F# 更易學、更統一
F# 6 啟用expr[idx]索引語法。到目前為止，F# 一直使用 expr.[idx] 進行索引。刪除點符號是基于第一次使用 F# 用戶的反復反饋，點的使用與他們期望的標準實踐有不必要的差異。在新代碼中，我們建議系統地使用新的 expr[idx]索引語法。作為一個社區，我們都應該切換到這種語法。
F# 社區為使 F# 語言在 F# 6 中更加統一做出了重要改進。其中最重要的是消除了 F# 縮進規則中的一些不一致和限制。使 F# 更加統一的其他設計添加包括添加as圖案；在計算表達式中允許“重載自定義操作”（對 DSL 有用）；允許_丟棄use綁定并允許%B在輸出中進行二進制格式化。F# 核心庫添加了用于復制和更新列表、數組和序列的新函數，以及其他NativePtr內在函數。自 2.0 起棄用的 F# 的一些舊功能現在會導致錯誤。其中許多更改更好地使 F# 與您的期望保持一致，從而減少意外。
F# 6 還增加了對 F# 中其他“隱式”和“類型導向”轉換的支持。這意味著更少的顯式向上轉換，并為 .NET 樣式的隱式轉換添加了一流的支持。F# 也進行了調整，以更好地適應使用 64 位整數的數字庫時代，并隱式擴展了 32 位整數。
▌改進 F# 工具
F# 6 中的工具改進使日常編碼更容易。新的“管道調試”允許您單步執行、設置斷點并檢查 F# 管道語法input |> f1 |> f2 的中間值。陰影值的調試顯示已得到改進，消除了調試時常見的混淆源。F# 工具現在也更高效，F# 編譯器并行執行解析階段。F# IDE 工具也得到了改進。F# 腳本現在更加健壯，允許您通過global.json文件固定使用的 .NET SDK 版本。
熱重載
Hot Reload 是另一個性能特性，專注于開發人員的生產力。它使您能夠對正在運行的應用程序進行各種代碼編輯，從而縮短您等待應用程序重新構建、重新啟動或重新導航到您在進行代碼更改后所在位置所需的時間。
Hot Reload 可通過dotnet watch CLI 工具和 Visual Studio 2022 使用。您可以將 Hot Reload 與多種應用類型一起使用，例如 ASP.NET Core、Blazor、.NET MAUI、控制臺、Windows 窗體 (WinForms)、WPF、WinUI 3、Azure 函數等。
使用 CLI 時，只需使用 啟動您的 .NET 6 應用程序dotnet watch，進行任何受支持的編輯，然后在保存文件時（如在 Visual Studio Code 中），這些更改將立即應用。如果不支持更改，詳細信息將記錄到命令窗口。
此圖像顯示了一個使用 dotnet watch. 我對.cs文件和.cshtml 文件進行了編輯（如日志中所述），兩者都應用于代碼并在不到半秒的時間內非常快速地反映在瀏覽器中。
使用 Visual Studio 2022 時，只需啟動您的應用程序，進行支持的更改，然后使用新的“熱重載”按鈕（如下圖所示）應用這些更改。您還可以通過同一按鈕上的下拉菜單選擇在保存時應用更改。使用 Visual Studio 2022 時，熱重載可用于多個 .NET 版本，適用于 .NET 5+、.NET Core 和 .NET Framework。例如，您將能夠對按鈕的OnClickEvent 處理程序進行代碼隱藏更改。應用程序的 Main 方法不支持它。
注意：RuntimeInformation.FrameworkDescription 中存在一個錯誤，該錯誤將在該圖像中展示，很快就會修復。
Hot Reload 還與現有的 Edit and Continue 功能（在斷點處停止時）以及用于實時編輯應用程序 UI 的 XAML Hot Reload 協同工作。目前支持 C# 和 Visual Basic 應用程序（不是 F#）。
安全
.NET 6 中的安全性得到了顯著改進。它始終是團隊關注的重點，包括威脅建模、加密和深度防御防御。
在 Linux 上，我們依賴 OpenSSL 進行所有加密操作，包括 TLS（HTTPS 必需）。在 macOS 和 Windows 上，我們依賴操作系統提供的功能來實現相同的目的。對于每個新版本的 .NET，我們經常需要添加對新版本 OpenSSL 的支持。.NET 6 增加了對OpenSSL 3的支持。
OpenSSL 3 的最大變化是改進的 FIPS 140-2模塊和更簡單的許可。
.NET 6 需要 OpenSSL 1.1 或更高版本，并且會更喜歡它可以找到的最高安裝版本的 OpenSSL，直到并包括 v3。在一般情況下，當您使用的 Linux 發行版默認切換到 OpenSSL 3 時，您最有可能開始使用 OpenSSL 3。大多數發行版還沒有這樣做。例如，如果您在 Red Hat 8 或 Ubuntu 20.04 上安裝 .NET 6，您將不會（在撰寫本文時）開始使用 OpenSSL 3。
OpenSSL 3、Windows 10 21H1 和 Windows Server 2022 都支持ChaCha20Poly1305。您可以在 .NET 6 中使用這種新的經過身份驗證的加密方案（假設您的環境支持它）。
感謝 Kevin Jones 對 ChaCha20Poly1305 的 Linux 支持。
我們還發布了新的運行時安全緩解路線圖。重要的是，您使用的運行時不受教科書攻擊類型的影響。我們正在滿足這一需求。在 .NET 6 中，我們構建了W^X和英特爾控制流強制技術 (CET)的初始實現。W^X 完全受支持，默認為 macOS Arm64 啟用，并且可以選擇加入其他環境。CET 是所有環境的選擇加入和預覽。我們希望在 .NET 7 中的所有環境中默認啟用這兩種技術。
更多攻略歡迎轉到下一篇文章，繼續閱讀哦！
?了解更多.NET 6?
總結
以上是生活随笔為你收集整理的.NET 6 攻略大全（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一点杂感 以及 java8 Stream
- 下一篇： asp.net ajax控件工具集 Au