引言
将 ASP.NET MVC 应用从.NET Framework 升级到现代.NET 并不是简单的版本提升。此次迁移代表了运行时、托管模型、配置系统、依赖注入和 HTTP 流水线架构的转变。许多团队低估了这一点，把它当作标准的框架升级，结果在流程后期才发现他们应用中的核心假设已经不再成立。
好消息是，Microsoft 提供了明确的指导和模式，使得正确操作时迁移过程可预测。本文介绍了一个实用的逐步策略，如何将基于.NET Framework 构建的 ASP.NET MVC 5 应用迁移到运行在现代.NET 上的 ASP.NET Core，同时最大限度地减少风险和停机时间。
本指南是为已经了解 ASP.NET MVC 并希望有一条切实可行、准备好生产的开发者写的。
步骤1：根据应用大小选择迁移路径
选择这两条路中的一条：
大多数真实应用的增量迁移
你会在旧应用前面搭建一个新的 ASP.NET Core 应用，逐步迁移路由和功能，迁移时保持旧应用的存在。Microsoft 推荐这种方法用于大规模迁移。小型应用的 Big Bang 迁移
你创建一个新的 ASP.NET Core MVC 应用，移植控制器、视图和服务，直到一切运行完毕，然后切换。
如果不确定，默认采用增量迁移，因为这样可以降低切换风险。
步骤2：清点什么会阻挡你
列出迁移过程中常需要改进的依赖和应用功能：
System.Web 的使用
像 HttpContext.Current、HttpModules、HttpHandlers、Global.asax 以及经典流水线功能这些功能不会直接迁移。认证与授权
ASP.NET Core 采用了不同的模式。会话、缓存、配置、日志
API 和模式各不相同，需要有意识的迁移规划。
快速对你的 NuGet 包做个兼容性检查。对于每个软件包，检查它是否支持 netstandard2.0 或现代网络版本，或者是否有 ASP.NET Core 替代品。标记所有与 System.Web 相关的内容。
步骤3：在接触代码前建立安全基线
冻结当前状态：
- 给仓库标记
- 确保你能构建解决方案并运行测试套件
- 如果覆盖率较少，可以增加或加强测试
重点关注关键路由、授权流程和最重要的业务操作。
如果无法快速添加测试，至少要记录烟雾测试脚本和预期输出。
步骤4：先升级库，再考虑网页应用
这是杠杆最高的操作。如果还没拆分，就把解决方案分成几层：网页项目、应用服务、域名、数据访问、共享工具。
先移植类库。如果可能，把库转换成目标 NetStandard2.0 作为桥接，或者直接面向现代 .NET。修复编译错误并替换不支持的 API。
Microsoft 的通用移植指导是评估项目，并以降低初始升级后复杂性的方式推进各个部分。
步骤5：决定是否使用迁移工具
你可以使用两个 Microsoft 支持的工具指令来加快部分工作速度：
.NET 升级助手
它帮助升级项目并分析不兼容问题，包括 .NET Framework 项目。在有帮助的地方使用它，但不要指望它能完全把 ASP.NET MVC 5 应用自动转化为 ASP.NET Core MVC。ASP.NET Framework 应用的迁移工具
Microsoft 指出，将 ASP.NET 框架 MVC、Web API 和 Web Forms 项目升级到 ASP.NET Core，提供专用的现代化工具。
如果你愿意，你仍然可以手动完成所有操作，但工具可以减少枯燥的机械编辑。
步骤6：创建新的 ASP.NET Core MVC 主机应用
即使是增量迁移，这一步也必须，因为你需要一个 ASP.NET Core 应用才能在现代.NET 上运行。
创建一个新的 ASP.NET 核心 MVC 项目，使用标准的 ASP.NET 核心 MVC 模板。添加你的核心包、日志、配置和 DI 结构。
在 ASP.NET Core 中，Program.cs 配置主机和中间件流水线。没有 Global.asax。添加一些你肯定需要的基础中间件：路由、静态文件、认证和授权（如适用）、MVC 端点。
最小示例形状：
/* by yours.tools - online tools website : yours.tools/zh/tempemail.html */ var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllersWithViews(); var app = builder.Build(); app.UseStaticFiles(); app.UseRouting(); app.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); app.Run();步骤7：先移动路由，然后是控制器，最后是视图
Microsoft 的 MVC 到核心示例攻略从设置开始，然后是控制器和视图，最后是静态内容和客户端依赖。遵循这个顺序，因为这样可以让迁移在每一步都可测试。
迁移路由
在 MVC 5 中，你很可能用过 RouteConfig，可能还用了属性路由。在 ASP.NET Core 中，你配置中间件流水线和端点映射中的路由。
迁移控制器
一次迁移一个控制器。复制一个控制器类。通过更换命名空间和替换依赖 System.Web 的代码来修复编译错误。用控制器 HttpContext 访问替代 HttpContext.Current 模式。
迁移视图
Razor 语法类似，但辅助器和一些功能有所不同。需要的地方转换 HTML 辅助工具，必要时使用标签辅助工具。
你很可能会引入 ViewImports.cshtml 和 ViewStart.cshtml 的模式。
步骤8：移动静态文件和客户端依赖
静态文件
在 MVC 5 中，你可能用过内容和脚本的约定。在 ASP.NET Core 中，默认是 wwwroot 加 UseStaticFiles 中间件。
捆绑与精简
如果你依赖 System.Web.Optimization，可以用现代前端构建流水线或其他支持的方法替代它。
Microsoft 的示例迁移流程明确指出静态内容和客户端依赖是早期迁移步骤。
步骤9：将配置从 Web.config 迁移到 appsettings
确定你在 Web.config 中存储了什么：连接串、应用设置、认证设置、自定义配置部分。
将设置迁移到 appsettings.json 和环境特定的 appsettings 文件中。通过构建器读取 ASP.NET 核心配置系统中的设置。
Microsoft 有专门的 MVC 迁移示例中的迁移配置指南。
步骤10：迁移认证和授权
确定你当前的认证模型：表单认证、OWIN cookies、ASP.NET MVC 5 中的身份、Windows 认证。
在 ASP.NET Core 中实现类似的：
- 在 DI 中配置认证服务
- 在流程中加入中间件
- 端口授权属性和策略
Microsoft 的 MVC 迁移示例指向了针对认证和身份迁移的专门指导，因为这通常是较为繁重的部分之一。
步骤11：迁移数据访问
如果你使用实体框架6
你通常可以保留 EF6 一段时间，即使是在现代.NET 上，这取决于你的配置。从长远来看，许多团队转向 EF Core 以获取现代化的模式和功能。
如果你用 ADO.NET 或 Dapper
这些通常能干净地移植，但你会更新配置和依赖注入模式。
步骤12：运行应用，修复运行时问题，然后进行优化
按这个典型顺序修复运行时问题：
- 配置与环境差异
- 中间件排序问题
- 身份验证与 Cookie
- 会话与缓存行为
运行自动化测试和烟雾测试。在适当情况下添加结构化日志和健康检查。
步骤13：如果你选择了增量迁移，设置"前门"Core 应用
对于增量迁移，关键举措是将 ASP.NET 核心应用置于现有的.NET Framework 应用之前，并逐路由迁移。Microsoft 关于增量迁移的"入门指南"推荐采用代理前线方法进行大规模迁移。
你的流程变成：
- 路由 A 由 ASP.NET 核心处理，其他所有路由代理到 MVC 5
- 一次移动一个垂直切片
- 当所有路线都被迁移后，关闭旧的 MVC 5 应用
步骤14：生产切换清单
主持
决定 IIS 在流程中、IIS 在流程外，还是容器。
可观测性
在增量迁移过程中，两个应用的日志、指标和追踪都对齐了。
安全
Cookie 设置、数据保护密钥、TLS、头部。
性能
迁移后确认缓存和会话行为。
结论
将 ASP.NET MVC 应用从.NET Framework 迁移到现代.NET 是一项战略投资，而非机械升级。正确执行时，它能带来更清晰的架构、性能提升、云准备度提升以及长期平台支持。
通过将迁移拆分为有计划、可测试的步骤，并优先关注架构而非语法，团队可以自信地现代化，同时不扰乱生产系统。
这种方法在现实企业迁移中已被反复证明有效，并且符合 Microsoft 推荐的 ASP.NET 应用现代化战略。
本文是由葡萄城技术开发团队发布，转载请注明出处：葡萄城官网
