.NET 11 预览 3:开发人员的评论
每个团队都知道,升级旧的.NET应用程序并不是难题。 更换目标框架只需一个下午。 难点在于代码库在十年中悄然依赖的一切:仅能在Windows上运行的依赖,没人完全记得的数据流,如果处理方式不当会在生产中崩溃的组件。 现代化改造工作总是在这些方面停滞,而完成这些工作的压力仍在提高。
会话以Forrester数据图开启:94%的IT领导者称应用现代化改造是未来6到12个月的投资重点。 幻灯片上的强调,对工程师而言,"但您需与技术债务争斗。"这种紧张关系正是此次会话存在的全部理由。

这是Jeff Fritz, Nish Anil和Hazem El-Hammamy在Build 2026分会场中的一个AI代理面对的任务,使用AI工具为旧应用教授新招( BRK220)。 会话展示了GitHub Copilot的现代化能力如何应对工程师厌恶的工作内容:阅读大型代码库、绘制其依赖关系、规划升级并在大规模安全重构。 我们从我们工作的层面,即文档生成和处理的角度来观察,并得出了最有用的收获,即AI代理呈现出的内容,而不仅仅是它改写的内容。
有趣的部分在于依赖关系图
Jeff的会话部分是.NET开发者的实际视角:将代理指向真实的旧应用,让其解开复杂关系。 手动分析一个代码库和追踪数据流是将现代化改造变成一季以上项目的步骤,因为它既慢又容易出错。 可以遍历整个项目群,构建依赖关系图并标记出无法迁移的部分的代理将此步骤从几周压缩为一个工作会话。

它标记的内容比速度更重要。 当代理绘制依赖关系时,它在寻找阻挡目标环境的事物,而一个特定类别会在旧.NET应用中重复出现:依赖运行机器的代码。 经典的例子是文档处理。 惊人数量的老旧业务逻辑通过Office自动化,COM互操作或假设桌面的打印驱动生成PDF、电子表格和Word文件。这些代码在2015年的Windows服务器上运行良好,但无法迁移到Linux容器或Azure函数,因为不存在可自动化的Office,也没有可调用的COM。 代理将其视为一个阻碍。 问题是您要将其重构为何?
重构为可随迁移的依赖项
这是现代化过程中决定文档层的时刻,也是我们工作的所在。 迁移的全部目的是到达一个发展良好的环境:容器、无服务器、跨平台的持续集成。 因此,替换机器绑定文档代码的需要是一个不包含这些假设的托管.NET库。
当问题是PDF生成时,IronPDF从HTML用纯.NET渲染PDF,不需要Office和互操作,因此重构后的代码在现代化应用迁移到的同一个容器中运行。 当是电子表格自动化时,IronXL读取和写入Excel文件无需Office Interop或COM,这正是代理标记的依赖。 同样,使用IronWord进行Word生成,对于旧应用常用的脆弱工具进行的扫描文档和图像到文本路径,IronOCR保持该步骤在过程中。 每一个都是重构的直接目标:代理识别出COM或互操作调用,新的代码是一个在每个平台上表现相同的库。
这与代理重构配合良好的原因是替代方案是确定性的。 当新的API是返回真实文件、无头运行并不需要主机配置的普通.NET库时,代理可以自信地重写调用站点。 目标上无需安装任何东西、无需每台机器的软件许可、无需依赖操作系统。 这是让"在大规模的情况下安全重构"真正安全的特性。
一个具体形状
综上所述,现代化循环看起来像这样。 代理分析旧应用并构建依赖关系图。在阻碍因素中,它标记了一个通过Office自动化生成发票的报告模块,这种代码在应用程序在容器中运行时就会失败。 升级计划要求替换它。 代理将调用站点重构为托管库,发票PDF使用IronPDF,数据导出使用IronXL,现在模块在与其他所有东西相同的Linux容器中运行。 应用程序迁移,文档层随之迁移,而不是将其固定在Windows上。
这是现代化框架和现代化应用之间的区别。框架升级是机械的。 只有在其依赖迁移时,应用程序才真正移动,而文档层是阻挡其后退的最常见事物之一。
接下来该去哪里
会话指向GitHub Copilot现代化文档和命令中心、规则书和大型机能力的私人预览注册。 Microsoft通过虚拟.NET代理现代化日6月16日续写这个主题,完整的Build功能列表涵盖所有已发布内容。 相关的分会场现代化智能应用和代理随您的成长和扩展(OD801)值得与本次会话搭配。
如果您计划进行现代化检测,知道哪些阻碍因素与文档相关在代理找到它们之前是值得的。 IronPDF, IronXL, IronWord和IronOCR都提供免费试用,或是完整套装Iron Suite,因此在依赖关系图返回时您可以准备好重构目标。 代理可以教会旧应用很多新技巧。 给它一个干净的落脚点仍然是工程师的决定。

