LeadByExample()：Jakub Chodounsky談務實工程、YOLO心態以及為何最佳實踐並非總是最佳

流程API：多年間最重要的更新

System.Diagnostics.Process在幾個發布週期中首次獲得了實質性更新，並且它精確地解決了程式庫作者多年來一直在繞過的問題點。 這與我們的工作直接相關。 IronPDF在內部包裝了一個Chromium渲染過程，這意味著我們的團隊已經在同樣的領域上構建並維護了自定義解決方案，而這些領域現在已經被微軟標準化了：進程生成、無死鎖的輸出捕獲、跨平台的生命週期管理以及可靠的終止行為。

新的API表面看起來就像是程式庫團隊多年來繞過的問題的目錄：

// One-line execution with no deadlock risk
string output = await Process.RunAndCaptureTextAsync("git", ["log", "-5"]);

// Cross-platform parent-exit behavior
var psi = new ProcessStartInfo("renderer.exe")
{
    KillOnParentExit = true,
};

// One-line execution with no deadlock risk
string output = await Process.RunAndCaptureTextAsync("git", ["log", "-5"]);

// Cross-platform parent-exit behavior
var psi = new ProcessStartInfo("renderer.exe")
{
    KillOnParentExit = true,
};

Imports System.Diagnostics
Imports System.Threading.Tasks

' One-line execution with no deadlock risk
Dim output As String = Await Process.RunAndCaptureTextAsync("git", {"log", "-5"})

' Cross-platform parent-exit behavior
Dim psi As New ProcessStartInfo("renderer.exe") With {
    .KillOnParentExit = True
}

RunAndCaptureTextAsync多路複用stdout和stderr以消除管道緩衝區的死鎖。 KillOnParentExit和StartDetached提供了跨平台控制子進程生命週期的功能，適用於Windows和Linux。 InheritedHandles允許明確指定子進程繼承的句柄, 替代了過去廣泛繼承的預設設定。 輕量級的SafeProcessHandle表面生成的NativeAOT二進制文件比標準API小20%。

對於任何建立.NET軟體以協調子進程的團隊來說，本節的發布說明值得仔細檢視。

對於那些不願在內部建立或維護這種基礎架構的團隊，IronPDF提供了盒裝測試的這些模式的實現：無死鎖的輸出捕獲、生命週期控制及可靠的故障處理。 開始免費試用Iron Suite，不需要信用卡。

基於Span的Deflate、ZLib和GZip API

這項變更在發布說明中不那麼顯眼，但實質上改善了任何處理壓縮資料的工作負載。 PDF文件包含壓縮的內容流。 XLSX文件是壓縮XML的ZIP檔案。 DOCX也是遵循相同的模式。 新的基於跨度的編碼器和解碼器API減少了分配，這正是像IronPDF和IronXL這些程式庫持續進行的操作。

這些是基礎設施級別的改善，很少上發布頭條，但降低了每個字節通過框架處理的成本。

Runtime Async，現在編譯進入框架程式庫中

預覽版3去除了Runtime Async的預覽功能閘。 預覽版4進一步擴展了這一功能：運行時程式庫本身（整個BCL，包括System.IO和System.Net.Http）現在是使用運行時異步編譯的。 每個異步調用到框架中現在都使用新的續約機制，無論消費程式碼是否啟用了該功能。

對於進行大量I/O（讀取文件，下載遠程資源，通過編解碼器流字節）的程式庫來說，這代表了依賴性能的實質性改進，無需消費者做出任何改變。 來自Runtime團隊的Andy Gocke已經確認，當使用MemoryStream支持時，手動啟用的DecompressAsync產生零額外的記憶體分配。 微軟尚未發布正式的基準測試資料，指出需要完成其完整性能測試套件，但結構性變更已到位。

MAUI移動到CoreCLR

這是本次發布中的最重要的架構變更，雖然對我們產品線的直接影響有限。 從預覽版4開始，Android、iOS和Mac Catalyst上的MAUI應用程式將預設運行在CoreCLR上，結束了.NET移動運行時超過十五年的Mono時代。 同一運行時現在支持ASP.NET Core、桌面應用程式和移動應用。dotnet watch 現在也可以在Android和iOS上使用，解決了自MAUI首次發布以來的開發者體驗缺口之一。

對於在MAUI應用程式中使用IronBarcode或IronPDF的團隊來說，底層運行時現在和.NET堆棧的其餘部分統一了。

已知的限制和考量

• Visual Studio支持仍然僅限於Insiders通道。 使用穩定版Visual Studio的團隊尚未將.NET 11整合到主流開發中。
• Runtime Async結構性到位，但缺乏官方基準測試資料。 廣泛流傳的"10M awaits：80ms到32ms，687MB到94KB"資料來自社區要點而非微軟。
• MAUI CoreCLR轉換是一個運行時變更作為預設運行。 現有的MAUI應用程式應在實體裝置上進行測試，而不是假設為透明升級。
• 像任何預覽版一樣，生產部署應等待至少第一個候選版本。

摘要

預覽版4代表了至今為止.NET 11週期最強的變革組合。 流程API重寫是對於建立或運行.NET軟體以生成子進程的團隊最重要的更新。 壓縮和Runtime Async的改進在I/O密集型工作負載中形成復合效應。 MAUI的運行時故事現在與平台的其他部分保持一致。

我們的團隊正在積極跟踪每個預覽版，並準備我們的程式庫，以確保在 .NET 11 於十一月達到普遍可用性時，能夠即時相容。