產業新聞

您的Microsoft Build 2025指南 - 使用Iron Software的開發者應該注意什麼

已更新:

.NET 11進入其第三次預覽，距計劃於2026年11月GA（一般可用）還有大約六個月，與主要是底層設計的預覽1和2不同，預覽3是您實際能感受到版本形態的一個。

運行時異步不再是"預覽功能閘"的實驗，JIT（即時編譯器）進行了一批免費優化，ASP.NET Core原生支持Zstandard，還有C# 15的聯合型別——人們大約過去十年來一直在詢問的語言功能。

這不是一個LTS（長期支持）版本，.NET 11是下一個標準期限支持版本，提供24個月的支持，這已經改變了您是否升級的計算方式。 以下是作為開發者值得您關注的實質性內容以及仍然存在的粗糙邊緣。

C# 15聯合型別：重要的一項

如果您一直在編寫OneOf<T1, T2> 程式庫、自行編寫封閉的記錄階層或只是羨慕F#開發者，這就是重點。C# 15引入了一個union關鍵字，聲明一個值是固定型別集合中的一個，具有編譯器強制的完備性。 聯合型別已在預覽2中推出； 預覽3完善了對它們的IDE支持。

C#團隊的做法與F#的判定聯合更像是一個型別聯合：成員型別是您單獨定義的現有型別，並不是巢狀在聯合聲明中的標籤案例。 聯合本質上是一個包裹物件的結構體，並限制可以包裹在其中的內容。 從調用點來看，它感覺上是原生的——從成員型別到聯合的隱式轉換，對Pet.Value 的完備性切換表達式，以及當編譯器能看到所有情況時不需要預設分支。

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};

<Union>
Public Partial Structure Pet
    Implements IUnion

    Public Sub New(dog As Dog)
    End Sub

    Public Sub New(cat As Cat)
    End Sub

    Public Sub New(bird As Bird)
    End Sub
End Structure

Function Describe(pet As Pet) As String
    Return pet.Value Select Case
        Case d As Dog
            Return $"Dog named {d.Name}"
        Case c As Cat
            Return $"Cat ({c.Color})"
        Case b As Bird
            Return $"Bird, {b.Species}"
        ' no default - compiler knows the set is closed
    End Select
End Function
$vbLabelText   $csharpLabel

優點是明顯的：封閉型別、沒有無效狀態、在編譯時而不是NotImplementedExceptionat 凌晨三點的完備性。 向聯合中新增一個鯊魚，每個針對Pet的切換都會顯示警告，直到您處理它。

缺點同樣明顯，值得在任何誠實的評審中標記出來。 暴露的物件值屬性是一個不良設計——關於在GitHub上隱藏它並採用更型別安全的方法的討論仍在進行中。 公用構造函式隱含地定義了聯合接受的型別，這既不可發現又不顯式。 F#互操作性尚未解決（這兩種模型根本不同）。 而更廣泛的完備性故事仍有空白：封閉階層和封閉枚舉，這兩個提案將完整這一圖景，但仍然只是提案。 僅憑聯合本身是很棒的。 聯合加上封閉枚舉和封閉階層將帶來代際轉變。 我們還未達到那個程度。

運行時異步V2和JIT改進

運行時異步是.NET對異步/等待執行方式的靜默重寫。 取代在每個異步方法產生狀態機類的C#編譯器，運行時本身管理掛起和恢復。 可見的回報：更簡潔的堆疊跟踪、更小的分配，以及在除錯器中不用滾動經過 MoveNext 幀來找到您自己的程式碼。

在預覽3中，運行時異步放棄了EnablePreviewFeatures 要求。 您仍須切換功能開關 - <Features>runtime-async=on</Features> - 但不再需要將每個API調用都置於預覽領域。 NativeAOT和ReadyToRun支持也在此預覽中登陸，縮小了JIT和AOT場景之間的差距。 連續性物件得到更積極的重用，且未改變的局部變數不會在掛起間被保存。 在異步重度程式碼路徑中——如Kestrel管道或EF Core查詢工作——這意味著一個顯著的分配壓力下降。

JIT獲得了通常的"您的現有程式碼現在更快了，無需操作"的優化：

  • 多目標切換表達式如x是0或1或2或3或4現在折疊到無分支檢查。
  • 對數值[^1] + 數值[^2]模式的邊界檢查被更積極地消除，而在迴圈中常見的i + cns < len 情況整潔地崩塌。
  • 無符號整數到浮點和無符號整數到雙精度的轉換在預AVX-512 x86硬體上更快——這如果您在較舊的裝置上，可能是小眾但真實的。

WebAssembly使用者可在運行時直接獲得WebCIL載荷載入、更好的除錯符號，以及float[] / Span<float> / ArraySegment<float> 調用，而不需預設的往返開銷。 這些單獨的變化都不顯著，但共同構成了一種複合工作，使Blazor WASM感覺不那麽像一種妥協。

唯一的問題是硬體的最低要求。 .NET 11提高了x86/x64和Arm64的最低指令集需求。Apple Silicon和大多數Linux SBC沒問題——ReadyToRun目標在Arm64上僅增加了LSE——但非常舊的x86硬體已被排除。 在假設原地升級之前，請審核您的裝置。

ASP.NET Core and Blazor

Zstandard is the headliner here. ASP.NET Core現在支持zstd進行響應壓縮和請求解壓縮，當您加入中介軟體時，即被預設啟用。 配置是您所期望的形態：

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions { Quality = 6 };
});

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions { Quality = 6 };
});

Imports Microsoft.Extensions.DependencyInjection

builder.Services.AddResponseCompression()
builder.Services.AddRequestDecompression()
builder.Services.Configure(Of ZstandardCompressionProviderOptions)(Sub(options)
    options.CompressionOptions = New ZstandardCompressionOptions With {.Quality = 6}
End Sub)
$vbLabelText   $csharpLabel

對於API向那些已經支持zstd的客戶端提供JSON或文字載荷——在行動和gRPC相關生態系統中越來越常見——這是一種無需依賴第三方程式庫的可測量帶寬提升。 值得注意的是，這是社區的貢獻，而非微軟內部的貢獻，這是一個健康的信號。

Blazor的Virtualize<TItem>終於不再假設每行的高度相同。 這是一個長期困擾的問題：任何有變數內容的列表——評論、聊天消息或任何帶有換行文字的東西——都需要手動解決方法。 現在，元件在運行時測量項目。在預覽3發行還修復了多個Blazor錯誤：Virtualize中的空引用，帶有overflow-x的滾動容器檢測、發布的WASM應用中的Web Worker範本、ResourceCollectionProvider洩漏。 獨立來看小，但總體上的清理表明框架正超過"每次發行新事物"的階段。

Kestrel也開始在不等待控制流和設定框架的情況下處理HTTP/3請求，這減少了新連接上的第一次請求延遲。 如果您一直在測量HTTP/3 P99並看到奇怪的冷啟動後尾，這就是您的修正方法。

.NET MAUI

預覽3中的MAUI主要是關閉感覺像是測試版已過長時間的差距。 Map控件獲得了針聚合、定制針圖標、定制JSON樣式以及圓、折線、多邊形上的點擊事件——這些都是現實生產地圖用户介面所需，且以前需在每個平台上使用自定義處理。 內建的LongPressGestureRecognizer現在可用，無需自行編寫。 預設情況下啟用隱含的XAML命名空間聲明，這減少了每個文件頂部的樣板程式碼。

平台等同獲得提升：Permissions.PostNotifications現在在iOS上實現（之前僅有Android），Android獲得了對Android 17和API等級37的預覽支持。

誠實評估：這是穩定、明智的迭代，不是重新發明。 2026年的MAUI在很大程度上比2023年的MAUI要好得多，但如果您更早的時候放棄了它，僅預覽3無法將您拉回。 如果您已經在使用MAUI，這些正是您想要的產品改進。

SDK，CLI，和.NET watch

這是小東西累積的部分。我認為真的會改變日常工作流程的一些功能：

.NET sln現在可以直接從CLI建立和編輯解決方案篩選器（.slnf）。 對於單一程式碼庫和大型微軟風格的解決方案，打開一個有200個專案的SLN去工作其中三個一直花費不小。現在您可以從終端範圍定義：

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
SHELL

文件基的應用（.NET run app.cs工作流程）終於支持#:include，這意味著C#腳本可以將助手拆分成單獨的文件。 結合Roslyn中的指令編輯完成，這推動文件基的應用從"玩具"演變為真正可行的自動化工具——一個批處理程式碼和小Python腳本多年前就擁有的利基市場。

.NET run -e FOO=BAR讓您無需導出shell狀態或編輯啟動配置文件即可在命令行上傳遞環境變數。 小但若您曾在三個終端打開不同ASPNETCORE_ENVIRONMENT值，您就會知道這痛苦。

.NET watch與Aspire應用宿主整合，崩潰後在下一次文件更改時自動重新啟動，並更優雅地處理WinForms和WPF的Ctrl+C（長期的小痛）。 .NET format接受--framework開關支持多目標的項目。 .NET test在MTP模式下支持--artifacts-path。 .NET tool exec / dnx不再需要額外的批准，這曾是一次工具運行中的摩擦點。

痛點

公平評論應當涵蓋粗糙邊緣，預覽3有這些。

工具故事較粗糙。 Visual Studio 2026在.NET 10發布六個月後仍處於預覽狀態，而微軟托管的構建代理尚無穩定VS 2026支持。 .NET 10 SDK補丁發布中的更改需要MSBuild 18 (VS 2026)，這明顯違反了微軟推廣的semver保證。 任何在微軟托管代理上運行CI的人要麼將SDK 10.0.4釘住，要麼切換到預覽構建映像。 如果您正在考慮將CI管道移至.NET 11預覽，請期待更多相同情況——預覽SDKs正如團隊自己承認的那樣，在10.0.2和10.0.3中曾打破東西，然後穩定下來。

運行時異步仍是自選。 即使預覽功能閘不見，您必須切換runtime-async=on。 這對於新程式碼沒問題； 但對於通過NuGet發佈的程式庫，您仍無法假設使用者開啟了該開關，因此實際好處延遲到功能預設開啟時（不在.NET 11中）。

硬體要求提高。 最低x86/x64指令集需求上升。大多數團隊不會注意到。一些會——如果他們不先審核，他們在部署時就會發現。

STS，而非LTS。 .NET 11支持24個月。 .NET 10，當前的LTS，支持36個月。 對於更新節奏較慢的公司，.NET 10仍是更保守的選擇，而採用.NET 11意味著提交到2028年的另一個升級。採用STS的理由是功能； 反對的理由是日曆。

預覽即預覽。 這不是穩定性抱怨——微軟的預覽過程很好——但預覽3不是釋放候選。 生產部署最早需要等待RC1。內部工具、側專案和探索是目前的正確範圍。

評決

如果您每天都寫C#，.NET 11預覽3本週值得安裝和試用——特別是動手試用聯合型別，這是多年度語言更改中的最重要的變化。 如果您維護程式庫，JIT和運行時異步工作意味著您的程式碼會在.NET 11上提高速度，不需編輯，這是最佳的升級。 如果您發佈MAUI應用，地圖和手勢工作是真正的進步。

如果您運行生產.NET工作負載，答案是無趣的：繼續計畫、繼續觀察並將GA加為北簽，11月份。 令人興奮的要素正在登陸，但工具鏈——VS、構建代理和SDK補丁節奏——是摩擦所在區域，尚未解決。

| --- |

Sources: .NET Blog announcement, What's new in .NET 11 (Microsoft Learn), Runtime release notes, ASP.NET Core release notes, SDK release notes, Explore union types in C# 15.