行业新闻

LeadByExample()：Jakub Chodounsky 谈实用工程、YOLO 心态以及为什么最佳实践不一定是最好的

已更新:

.NET 11的第四次预览现在可用，它带来了几项对图书馆作者和运营中.NET服务团队的变化。 在Iron Software，我们维护了一组.NET库，这意味着每次预览发布都会促使两个评估：对我们维护者有什么变化，以及对集成这些库到其应用程序的客户有什么变化。 下面是我们认为在Preview 4中最重要的更新。

进程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
}
$vbLabelText   $csharpLabel

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遵循相同的模式。 新的基于span的编码器和解码器API减少了由库如IronPDF和IronXL连续执行的操作所需的分配。

这些是基础设施级别的改进，通常不会成为发行亮点，但会降低通过框架处理的每字节成本。

运行时异步，现已编译入框架库

Preview 3移除了运行时异步的预览功能门槛。 Preview 4进一步扩展了这一点：运行时库本身（整个BCL，包括System.IO和System.Net.Http）现在使用运行时异步编译。 现今在框架中的每个异步调用现在都利用新的继续机制，无论使用代码是否启用了此功能。

对于大量进行I/O的库（读取文件、下载远程资产、通过编解码器流字节流动），这在不需要任何消费者端更改的基础上表示了依赖性能的显著改进。 Andy Gocke来自运行时团队已证实，手动启用的DecompressAsync在由MemoryStream备份时不会产生额外分配。 微软尚未公布官方基准数字，称需完成完整性能测试套件，但结构性变化已经到位。

MAUI迁移至CoreCLR

这是版本中最重要的架构变化，尽管对我们的产品线直接影响有限。 从Preview 4开始，Android、iOS和Mac Catalyst上的MAUI应用默认运行在CoreCLR，结束了超过十五年的Mono作为.NET移动运行时。 同一运行时现在支持ASP.NET Core、桌面应用和移动应用。dotnet watch现在也适用于Android和iOS，解决了自其首次发布以来MAUI开发人员体验中最常被提到的缺口之一。

对于在MAUI应用中使用IronBarcode或IronPDF的团队，底层运行时现在与其余的.NET栈统一。

已知的限制和考虑事项

  • Visual Studio支持仍限于Insiders通道。 使用稳定版Visual Studio的团队尚未将.NET 11整合到主线开发中。
  • 运行时异步已经结构化而落地，但缺乏官方基准。 "10M awaits: 80ms to 32ms, 687MB to 94KB"这个广为流传的数字出自社区要旨而非微软。
  • MAUI CoreCLR过渡是运行时变化，以默认形式发布。 现有MAUI应用程序应在实际设备上进行测试，而不是假设可透明升级。
  • 与任何预览一样，生产部署应该等待至少第一个候选发布版。

摘要

Preview 4代表了.NET 11周期中迄今为止最强的变化集。 针对构建或操作.NET软件以生成子进程的团队来说，进程API重写是最重要的更新。 压缩和运行时异步改进在I/O密集型工作负载中复合。 MAUI运行时故事现在与平台的其余部分一致。

我们的团队正在积极跟踪每个预览版，并准备我们的库，以便在.NET 11于11月达到普遍可用时实现第一天的兼容性。