作者：Jiachen Jiang
排版：Alan Wang

我們很高興與您分享 .NET 8 Preview 5 中的所有新功能和改進！此版本是 Preview 4 版本的后續(xù)版本。在每月發(fā)布的版本中，您將看到更多新功能。.NET 6 和 7 用戶可以密切關(guān)注此版本，而我們也正在努力使其更容易升級。

您可以下載適用于 Windows、macOS 和 Linux 的 .NET 8 Preview 5。

• 安裝程序和二進制文件
• 容器圖像
• 發(fā)行說明
• 已知的問題
• GitHub 問題跟蹤器

您可以查看 Preview 5 版本中 ASP.NET Core 中的新增功能，并了解 .NET 8 中的新增功能和即將推出的新功能。在整個版本中，這些新功能將會不斷更新。

Microsoft Build 2023 取得了巨大的成功，這很大程度上歸功于像您這樣的 .NET 開發(fā)者！.NET團隊舉辦的會議吸引了大量參與者，我們在會上討論了 .NET 8 中一些令人興奮的功能，并回答了與會者的問題。請加入 Microsoft Build 2023 的 .NET 團隊！

現(xiàn)在，讓我們來看看.NET 8 中的一些新功能。

SDK：Metrics API 的增強

Preview 5 包含對 Metrics API 的許多改進和更新，涵蓋了其他用例。

依賴關(guān)系注入 （DI） 友好指標 API

我們推出了 IMeterFactory 接口，該接口可以向 DI 容器注冊并用于隔離創(chuàng)建 Meter 對象。

// service is the DI IServiceCollection 
// Register the IMeterFactory to the DI container using the default meter factory implementation. 
services.AddMetrics();

您現(xiàn)在可以使用下面的代碼創(chuàng)建Meter工廠，并使用它來輕松創(chuàng)建新的 Meter 對象。

IMeterFactory meterFactory = serviceProvider.GetRequiredService<IMeterFactory>();MeterOptions options = new MeterOptions("MeterName")
{Version = "version",
};Meter meter = meterFactory.Create(options);

支持創(chuàng)建帶有標簽的 Meter 和 Instrument

Meter 和 Instrument 也可以使用附加的鍵值對標簽創(chuàng)建。該特性允許發(fā)布的特性聚合器根據(jù)這些標記區(qū)分聚合值。

MeterOptions options = new MeterOptions("name")
{Version = "version",// Attach these tags to the created meterTags = new TagList() { { "MeterKey1", "MeterValue1" }, { "MeterKey2", "MeterValue2" } }
};Meter meter = meterFactory.Create(options);Instrument instrument = meter.CreateCounter<int>("counter", null, null, new TagList() { { "counterKey1", "counterValue1" } });
instrument. Add(1);

SDK：源鏈接是 .NET SDK 的一部分！

.NET SDK 現(xiàn)在包含源鏈接，以便在檢查源鏈接的 NuGet 包時增強 IDE 體驗。目的是通過將源鏈接捆綁到 SDK 中來消除對單獨 PackageReference 的需要，更多包將默認包含此信息。我們相信這將為開發(fā)人員創(chuàng)造更好的 IDE 體驗！

源鏈接是一個與語言和源代碼管理無關(guān)的系統(tǒng)，用于為二進制文件提供一流的源代碼調(diào)試體驗。該項目的目標是讓任何人生成 NuGet 庫以便為其用戶提供源調(diào)試，而無需額外的工作。源鏈接受 Microsoft 支持，并由 .NET Core 和 Roslyn 等庫啟用。

Visual Studio 和許多其他編輯器支持在調(diào)試時從符號讀取源鏈接信息。編輯器可以為用戶下載并顯示適當?shù)奶囟ㄓ谔峤坏脑创a，例如來自 raw.githubusercontent，它可以在任意 NuGet 依賴項上啟用斷點和所有其他源調(diào)試體驗。

源鏈接的交付實現(xiàn)包括 git、GitHub、GitLab、Azure 存儲庫和 BitBucket 的提供程序，但 NuGet 上還有更多的提供程序可用。

您可以在學習文檔中找到有關(guān)源鏈接的詳細信息，并閱讀存儲庫文檔中有關(guān)可用設(shè)置的詳細信息。

SDK：新的 .NET 庫分析器

分析器類似于內(nèi)置于 SDK 和交互式開發(fā)環(huán)境 （IDE） 中的編碼伙伴，可在您編寫代碼時識別問題并提出更正建議。從 .NET 8 Preview 1 開始，我們的團隊添加了多個分析器和代碼修復器，幫助開發(fā)人員驗證正確和（或） .NET 庫 API 更高效使用。我們很高興地提到，這些分析器中的大多數(shù)都是由我們的社區(qū)成員實現(xiàn)的。我們要衷心感謝所有貢獻者的辛勤工作和奉獻精神。

分析器提案和貢獻者	描述	類別	嚴重性	幫助鏈接
將常量傳遞給標記為 [ConstantExpected] 的參數(shù) by @wzchua	當 ConstantExpected 屬性未正確應用于參數(shù)時，CA1856 會觸發(fā)。 當參數(shù)用 ConstantExpected 屬性注釋，但提供的參數(shù)不是常量時，CA1857 會觸發(fā)。 應使用常量以獲得最佳性能。	性能	CA1856: Error CA1857: Warning	CA1856, CA1857
使用 StartsWith 而不是 IndexOf ==0 by @Youssef1313	調(diào)用 String.StartsWith 比調(diào)用 String.IndexOf 并將結(jié)果與零進行比較以確定字符串是否以給定前綴開頭更高效、更清晰。	性能	Info	CA1858
建議使用具體類型以最大限度地發(fā)揮去虛擬化潛力 by @geeknoid	該規(guī)則建議盡可能將特定局部變量、字段、屬性、方法參數(shù)和方法返回類型的類型從接口或抽象類型升級為具體類型。 使用具體類型可以通過最小化虛擬或接口調(diào)度開銷并啟用內(nèi)聯(lián)來生成更高質(zhì)量的代碼。	性能	Info	CA1859
優(yōu)先選擇 .Length/Count/IsEmpty 而不是 Any() by @CollinAlpert	使用 Length、Count 或 IsEmpty 比調(diào)用 Enumerable.Any 擴展方法來確定集合類型是否有元素更高效、更清晰。	性能	Info	CA1860
將常量數(shù)組提取到靜態(tài)只讀字段 @steveberdy	作為參數(shù)傳遞的常量數(shù)組在重復調(diào)用時不會重用，這意味著每次都會創(chuàng)建一個新數(shù)組。 如果傳遞的數(shù)組未在調(diào)用的方法中發(fā)生變化，請考慮將其提取到靜態(tài)只讀字段以提高性能。	性能	Info	CA1861
不要將 OfType() 與不可能的類型一起使用 by @fowl2	Enumerable.Cast<T> 和 Enumerable.OfType<T> 需要兼容的類型才能按預期運行。 對于不兼容類型的元素，Enumerable.Cast<T> 將在運行時拋出 InvalidCastException。Enumerable.OfType<T> 永遠不會成功處理不兼容類型的元素，從而導致空序列。 泛型類型不支持擴展和用戶定義的轉(zhuǎn)換。	可靠性	Warning	CA2021
將參數(shù) null 檢查轉(zhuǎn)換為 ArgumentNullException.ThrowIfNull by @stephentoub	拋出助手比構(gòu)造新異常實例的 if 塊更簡單、更高效。 在此分析器中添加了四個分析器：ArgumentNullException、ArgumentException、ArgumentOutOfRangeException 和 ObjectDisposeException 拋出幫助器。	可維護性	Info	CA1510, CA1511, CA1512, CA1513

我們計劃繼續(xù)向 .NET 8 添加更多分析器，以幫助開發(fā)人員編寫更好的代碼，并期待社區(qū)做出更多的貢獻。對于社區(qū)來說，這是向 .NET 8 SDK 添加一個完整的新功能的絕佳機會。

如果您有興趣做出貢獻，請查看我們已準備好開發(fā)并標記為可獲取的分析器列表。

SDK：Linux 自包含

Linux 發(fā)行版構(gòu)建（源代碼構(gòu)建）SDK 現(xiàn)在可以構(gòu)建利用源代碼構(gòu)建運行時包的自包含應用程序。特定于發(fā)行版的運行時包將與源構(gòu)建 SDK 捆綁在一起。在自包含部署期間，將引用此捆綁運行時包，從而為用戶啟用該功能。請注意，MS 構(gòu)建的 SDK 沒有變化。

感謝我們的 Red Hat 合作伙伴，尤其是@tmds，感謝他們?yōu)榇斯δ茏龀龅膶氋F貢獻。

SDK：自包含不再是默認

從 .NET 6 開始，在發(fā)布期間指定運行時會導致以下警告：

> warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used.

對于 .NET 8，這種情況最終將消失。 展望未來，對于面向 net8.0 和更高版本目標框架的應用程序，-r/--runtime 將不再意味著 –self-contained。 如果您想要這種行為，您需要

• 顯式添加 CLI 選項，或
• 將<SelfContained>true</SelfContained>屬性添加到項目文件

面向 .NET 7.0 或更低版本的應用程序不受影響。您可以在我們發(fā)布的重大變更通知中了解有關(guān)此變更的更多信息。

我們做出這一更改是因為我們相信針對特定平臺是將運行時與該平臺捆綁在一起的獨立決定。 讓更多應用程序默認為依賴于框架的部署意味著可以安全地更新運行應用程序的運行時，而無需重建或重新部署。 與自包含部署相比，它還減少了應用程序的大小。

Alpine ASP.NET Docker 合成圖像

我們現(xiàn)在提供一個新的 ASP.NET Docker 圖像，該圖像使用更新的開箱即用 (R2R) 構(gòu)建變體（稱為“composite”）。 合成 R2R 圖像是通過將多個 MSIL 程序集編譯為單個 R2R 輸出二進制文件來構(gòu)建的。 合成圖像有幾個優(yōu)點：減少 JIT 時間、降低啟動性能以及減小 R2R 映像大小。

合成圖像具有更緊密的版本耦合。這意味著最終的應用程序運行不能使用不同版本的框架（例如 System.Reflection.Metadata 和（或） ASP.NET 二進制文件被嵌入到合成文件中）。這個限制就是我們制作新圖像風格的原因。 您的應用程序可能無法按照當前的構(gòu)建方式使用composite。

這個新的容器圖像是新功能。我們決定從基于 Alpine 的新變體開始。通常選擇 Alpine 圖像是因為它們的尺寸較小，這與該項目的目標是一致的。將來我們可能會擴展對其他圖像類型的支持，例如 distroless 圖像。

我們在哪里可以獲得合成圖像？

截至目前，合成圖像可在 mcr.microsoft.com/dotnet/nightly/aspnet 存儲庫中預覽。這些標簽在官方夜間 Dotnet Docker 頁面中以 -composite 后綴列出。

默認情況下，運行時主機在沒有RID圖的情況下確定RID特定資產(chǎn)

當運行帶有 Runtime (RID) 特定資產(chǎn)的應用程序時，主機會決定哪些資產(chǎn)與其運行的平臺相關(guān)。

這適用于應用程序本身和 AssemblyDependencyResolver 使用的解析邏輯。 默認情況下，在 .NET 8 中，此決定將不再使用 RID 圖，而是依賴于基于運行時本身構(gòu)建方式的已知 RID 列表。

事實證明，RID 圖的維護成本高昂、難以理解并且通常很脆弱。此更改是簡化 RID 模型的長期目標的一部分。

您可以在重大變更通知中閱讀有關(guān)此變更的更多信息。

Codegen

動態(tài)配置文件引導優(yōu)化 (PGO) 現(xiàn)在默認啟用，這意味著不再需要特殊的配置設(shè)置。 我們預計各類應用程序的性能將提高 5% 到 500%（合理預期為 15%），具體取決于應用程序瓶頸的性質(zhì)。 在我們約 4600 次測試的本地基準測試套件中，23% 的測試提高了 20% 或更多。

• Akka.Net
• Azure Active Directory Gateway
• Microsoft Graph

在過去的版本中，PGO 的客戶體驗一直都是積極的。但是，如果您是動態(tài) PGO 的新手，我們也期待聽到您的體驗反饋（無論好壞）。

如有必要，您可以通過以下方式選擇退出動態(tài) PGO：
<TieredPGO>false</TieredPGO>
在 .csproj 中或通過運行時配置或環(huán)境中的類似設(shè)置。

優(yōu)化 GC 類型的 ThreadStatic 字段訪問

標記為 ThreadStaticLocal 的字段訪問現(xiàn)在針對原始類型進行了優(yōu)化。我們還通過 PR#85619 優(yōu)化了引用類型字段訪問。 這些更改在許多基準測試中帶來了一些非常好的改進：（windows/arm64 上有 133 個，windows/x64 上有 23 個，16、13、11 個改進）。

Arm64

Preview 5 還帶來了一些細微優(yōu)化：

• 在 PR#85032 中，我們啟用了窺視孔優(yōu)化，以用 stp 替換 str 組。
• 在 PR#85657 中，我們啟用了窺視孔優(yōu)化，在 prolog 中用 ldp/stp 替換 ldr/str 組。

常規(guī)優(yōu)化

我們的團隊發(fā)布了許多常規(guī)優(yōu)化，包括：

• PR#85780 中對 movzx、movsx 和 movsxd 等 x64 指令進行了優(yōu)化，通過消除更多冗余 mov 指令，略微改進了代碼生成。
• PR#86318 改進了某些凍結(jié)對象（非 GC 對象）的常量折疊。 它將生成的代碼的大小減少了近 10 倍（例如，從 424 字節(jié)減少到 41 字節(jié)）。

AVX-512

• PR#85389 啟用了 AVX-512 進行區(qū)塊展開，這增加了以前用于回退到 memcpy/memset 的范圍，并將執(zhí)行時間縮短了一半。
• AVX512F、AVX512BW 和 AVX512CD 啟用了各種整數(shù)內(nèi)在函數(shù)，PR#85833。

社區(qū) PR（非常感謝 JIT 社區(qū)貢獻者！）

• @SingleAccretion 在Preview 5 中貢獻了 18 個 PR。其中大部分工作都集中在內(nèi)部 JIT 清理上，最終目標是大大簡化內(nèi)部表示 (IR)，特別是在分配/存儲方面。

  • PR#85180 標志著這項工作的開始，在未來的預覽中，它將導致 JIT 在編譯用戶函數(shù)時速度提高幾個百分點。

• @yesmey 啟用了 const 字符串的 StringBuilder.Append 功能，以解鎖更多 AVX-512 的使用。 它將 System.Tests.Perf_Enum 基準測試的執(zhí)行時間提高了 8%，將 StringBuilder 的執(zhí)行時間提高了 16%，PR#85894。

• @MichalPetryka 提交了 PR#85398，改進了 JIT 早期推理單定義變量的能力，并提交了 PR#85349，改進了 JIT 的代碼生成，以調(diào)用不帶參數(shù)的函數(shù)指針。

使用 C# 開發(fā)工具包擴展提高 VS Code 的工作效率！

VS Code 中的 C# 開發(fā)工具包擴展現(xiàn)在已經(jīng)可以 在 VS Code 中進行公開預覽！我們非常感謝您在 .NET 8 中使用C# 開發(fā)工具包 ，并給予反饋。

它旨在提高您在 VS Code 中的 C# 工作效率，C# 開發(fā)工具包可幫助你使用解決方案資源管理器管理代碼，使用 AI 輔助建議和完成，實現(xiàn)更快地編寫代碼，并提供在測試資源管理器中運行和調(diào)試測試的新功能。使用 Roslyn 支持的語言服務，C# 開發(fā)工具包還極大地提高了 C# 語言功能（如代碼導航、重構(gòu)、智能感知等）的性能。

如果您想要開始使用 C# 開發(fā)工具包，請查看我們最近的公告博客文章。

社區(qū)焦點

DoctorKrolic

我是一名 .NET 后端開發(fā)人員，對代碼分析應用程序充滿熱情。喜歡構(gòu)建強大的后端服務和 C# 生產(chǎn)力工具！在空閑時間，我喜歡為開源項目做出貢獻，并跟上最新的行業(yè)趨勢，以不斷提高我的技能和知識。

您可以在 https://aka.ms/net8contributor 提名您已知正在為 .NET 做出貢獻的人，我們將會在以后的帖子中介紹他。

總結(jié)

.NET 8 Preview 5 包含了令人興奮的新功能和改進，這些是通過 Microsoft 多元化工程師團隊和充滿熱情的開源社區(qū)的辛勤工作和奉獻而實現(xiàn)的。我們要感謝迄今為止為 .NET 8 做出貢獻的所有人，無論是通過代碼貢獻、錯誤報告還是提供反饋。

您的貢獻對于制作 .NET 8 預覽版發(fā)揮了重要的作用，我們期待著繼續(xù)共同努力，為 .NET 和整個技術(shù)社區(qū)打造更光明的未來。

好奇接下來會發(fā)生什么？ 快來親自看看 .NET 的下一步發(fā)展吧！