如何从 ASP.NET Framework 迁移到 ASP.NET Core

如果忽视这些挑战，迁移过程很可能会失败或无法顺利完成。

迁移策略选择

选择合适的迁移方案至关重要。

整体迁移方案

这种迁移方式意味着需要一次性重新编写整个应用程序的代码。

优点：

• 架构简洁清晰

• 不存在任何陈旧、过时的组件或技术

缺点：

• 风险较高

• 项目周期较长

• 需要进行全面回退测试

对于大型系统而言，这种迁移方式很少被推荐使用。

渐进式迁移（推荐方案）

在这种情况下，通常会采用“绞杀者藤蔓模式”。新功能会在ASP.NET Core中逐步开发出来，同时逐渐替换原有的组件。

“绞杀者藤蔓模式”这一名称来源于那种会缠绕在宿主树上并逐渐将其取代的藤本植物。在软件现代化改造中，这种模式意味着在现有应用程序的基础上不断添加新的功能，并在组件被迁移的过程中将特定的请求路由到新系统中。团队不会一次性替换整个应用程序，而是逐步“削弱”旧系统，直到全新的ASP.NET Core应用程序完全取代旧系统。

优点：

• 风险较低

• 能够实现持续交付

• 便于调试问题

混合式迁移方案

可以同时运行ASP.NET Framework和ASP.NET Core。某些模块（例如API接口）可以先进行迁移，而用户界面则保持不变。

优点：

• 迁移风险较低

• 对现有系统的干扰最小

• 支持分阶段部署

缺点：

• 会增加运营管理的复杂性

• 需要额外的部署工作量

• 会导致短暂的架构重复现象

对于那些业务连续性比快速完成迁移更为重要的大型企业系统来说，这种迁移方式尤为适用。

迁移前的评估工作

成功的迁移始于周密的规划。

代码库审计

• 识别可重复使用的模块

• 检测那些耦合度过高的组件

• 分析各组件之间的依赖关系

工具支持

可以使用以下工具来辅助迁移工作：

• .NET可移植性分析工具

• API分析工具

这些工具有助于判断现有代码与ASP.NET Core的兼容性。

明确迁移范围

首先需要确定哪些部分应该先进行迁移：

• API接口

• 用户界面（MVC视图层）

• 后台服务

逐步迁移流程

步骤1：升级现有应用程序

确保您的应用程序运行在最新版本的ASP.NET Framework上。这样就能最大限度地减少兼容性问题。

步骤 2：创建一个新的ASP.NET Core MVC项目

使用命令行工具进行操作：

dotnet new mvc -n ModernApp

这样会创建一个结构清晰、设计现代的项目：

• Program.cs（入口文件）

• Controllers/

• Views/

• wwwroot/

步骤 3：迁移配置文件

将web.config文件替换为appsettings.json文件。

旧的（web.config）格式：

<appSettings>
  <add key="ApiUrl" value="https://api.example.com" />
</appSettings>

新的（appsettings.json）格式：

{
  "ApiSettings": {
    "BaseUrl": "https://api.example.com"
  }
}

在代码中引用这些配置的方式：

public class HomeController : Controller
{
    private readonly IConfiguration _config;

    public HomeController(IConfiguration config)
    {
        _config = config;
    }

    public IActionResult Index()
    {
        var url = _config["ApiSettings:BaseUrl"];
        return View();
    }
}

步骤 4：用中间件替换Global.asax

ASP.NET Core使用中间件管道来处理请求，而非传统的生命周期事件模型。

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseRouting();
app.UseAuthorization();

app.MapControllers();

app.Run();

与旧的基于事件的架构相比，这种中间件管道提供了更大的控制灵活性。

步骤 5：迁移控制器和视图文件

控制器的逻辑基本保持不变，但返回类型有所调整。

ASP.NET Framework：

public ActionResult Index()
{
    return View();
}

ASP.NET Core：

public IActionResult Index()
{
    return View();
}

对于Razor视图文件，需要进行一些小的修改，尤其是涉及标签辅助函数的部分。

步骤 6：实现依赖注入机制

应使用依赖注入来替代那些耦合度较高的服务组件。

public interface IProductService
{
    List GetProducts();
}

public class ProductService : IProductService
{
    public List GetProducts()
    {
        return new List { "Laptop", "Phone" };
    }
}

服务注册：

builder.ServicesScoped<IProductService, ProductService>>();

在控制器中的使用：

public class ProductController : Controller
{
    private readonly IProductService _service;

    public ProductController(IProductService service)
    {
        _service = service;
    }

    public IActionResult Index()
    {
        var products = _service.GetProducts();
        return View(products);
    }
}

步骤 7：迁移数据访问层

大多数旧版应用程序都使用 Entity Framework。在 ASP.NET Core 中，你应该使用 Entity Framework Core。

DbContext 示例：

public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    public AppDbContext(DbContextOptions<AppDbContext>> options)
        : base(options) { }
}

在 Program.cs 中进行注册：

builder.Services.AddDbContext<AppDbContext>>(options =>
    options.UseSqlServer("YourConnectionString"));

步骤 8：身份验证与授权

ASP.NET Core 提供了多种灵活的身份验证机制：

• 基于 Cookie 的身份验证

• JWT 令牌

• OAuth 提供者

示例：

builder.Services.AddAuthentication("CookieAuth")
    .AddCookie("CookieAuth", config =>
    {
        config LoginPath = "/Account/Login";
    });

步骤 9：测试与验证

在迁移过程中，进行测试至关重要：

• 单元测试（xUnit, NUnit）

• 集成测试

• 回归测试

需要确保旧系统和新系统之间的功能一致性。

例如，在将旧的 ASP.NET Framework API 迁移到 ASP.NET Core 后，可以通过集成测试来验证其行为是否与原始系统一致。

示例：集成测试（xUnit）

[Fact]
public async Task GetProducts_ShouldReturnSuccessStatus()
{
    // 准备测试环境
    var client = _factory.CreateClient();

    // 执行操作
    var response = await client.GetAsync("/api/products");

    // 验证结果
    response.EnsureSuccessStatusCode();
}

在迁移过程中，你还可以将旧系统和新系统的接口进行对比：

• /legacy/api/products → ASP.NET Framework

• /api/products → ASP.NET Core

然后同时发送请求，验证响应在结构、状态码和数据完整性方面是否一致。这样就能确保迁移不会导致任何行为上的问题，在完全淘汰旧系统之前消除潜在风险。

性能与可扩展性提升

ASP.NET Core带来了诸多显著的改进：

• Kestrel Web服务器：高性能、跨平台的服务器

• 异步优先的设计理念：高效的请求处理机制

• 更低的内存占用

• 在高负载环境下具有更好的吞吐量

这些改进使得ASP.NET Core非常适合用于微服务架构及云部署场景。

部署方式的现代化

传统的应用程序通常与基于IIS的托管环境紧密绑定，这种架构限制了应用程序在部署和扩展方面的灵活性。而使用ASP.NET Core，现在可以借助现代、便携且自动化的基础设施技术来部署应用程序，这些技术更有利于支持云原生开发及持续交付流程。

容器化技术

容器化技术允许将应用程序及其所有依赖项打包成一个独立的、可移植的单元，这样该单元就能在不同环境中稳定运行。借助Docker等工具，ASP.NET Core应用程序可以在开发环境、测试环境和生产环境之间进行可靠部署，而不会出现因环境差异导致的配置问题。这种技术还简化了分布式系统中的扩展与回滚操作。

FROM mcr.microsoft.com/dotnet/aspnet:6.0
COPY . /app
WORKDIR /app
ENTRYPOINT ["dotnet", "ModernApp.dll"]

CI/CD集成

持续集成与持续部署流程能够自动化应用程序的构建、测试及部署过程。在迁移场景中，CI/CD技术尤为重要，因为它能确保传统组件与现代化组件在逐步替换的过程中保持稳定运行。GitHub Actions和Azure DevOps等平台有助于团队快速验证代码变更，从而降低从ASP.NET Framework迁移到ASP.NET Core时出现回归问题的风险。

使用CI/CD技术还能实现以下目标：

• 在分阶段迁移过程中加快发布周期

• 自动测试被迁移的模块

• 在部署失败时能够安全地进行回滚操作

这些功能确保了构建、测试和部署过程的自动化。

常见误区

低估复杂性

迁移过程并不仅仅是代码的转换，它还意味着需要重新设计整个应用程序架构。由于中间件、配置设置和托管环境的差异，团队往往必须对关键组件进行重新设计，而而不能简单地将其移植到新环境中。

忽略依赖关系

许多传统应用程序依赖于第三方库，而这些库可能并不支持ASP.NET Core。如果未能提前评估这些依赖关系的兼容性，就可能会在迁移过程中遇到各种问题，从而导致最后时刻才需要修改或替换相关代码。

渐进式迁移方法

尝试进行全面的“大爆炸式”迁移会增加风险，往往会导致延迟或失败。采用渐进式策略可以让团队逐步验证各项变更，在整个迁移过程中保持系统的稳定性。

测试不足

如果测试不够充分，就可能会在生产系统中引入严重的错误。全面的单元测试、集成测试和回归测试对于确保新应用程序的行为与旧系统一致而言至关重要。

实际应用案例

企业ERP系统的现代化改造

基于ASP.NET构建的大型ERP系统，由于其紧密耦合的架构，往往难以进行扩展和维护。将这些系统迁移到ASP.NET Core上，可以帮助企业将各个组件模块化，提升性能，并实现云部署。这种迁移方式还能使企业更容易引入微服务及现代的DevOps开发模式。

电子商务平台的扩展能力

电子商务应用程序需要具备高可用性，并能够应对流量激增的情况。通过迁移到ASP.NET Core，企业可以利用异步处理技术、优化的请求处理机制以及基于容器的扩展方案，从而实现更快的页面加载速度、更好的用户体验，并有效应对高峰需求。

以API为导向的后端改造

现代应用程序越来越多地采用以API为导向的设计思路，即将后端设计为一组独立的服务。ASP.NET Core简化了RESTful API的开发过程，提供了更完善的路由机制、序列化功能以及更好的性能表现。企业通常会先迁移API部分，从而建立起可扩展的后端架构，然后再逐步调整用户界面层，使其与新架构相匹配。

最佳实践检查清单

从一个小模块开始

不要试图一次性迁移整个应用程序，而应该先从一个风险较低的模块入手，比如报告功能或内部API。这样可以帮助团队了解迁移流程，及早发现潜在问题，并在逐步扩展迁移范围之前建立起信心。

采用渐进式迁移方式

像“绞杀者图”这种渐进式迁移策略，可以使旧系统与新系统在迁移过程中共存。这种方式能够减少停机时间，降低风险，并确保系统的持续运行，同时逐步用ASP.NET Core服务替换旧有的组件。

尽早进行依赖注入重构

依赖注入是ASP.NET Core的核心原则，尽早采用这一机制能够简化后续的开发工作。将紧密耦合的组件重构为松耦合的服务，可以提高测试性、可维护性，并提升迁移过程中及迁移后的代码质量。

持续监控性能

在整个迁移过程中，应利用日志记录和监控工具来跟踪系统的性能表现。通过对比旧系统与新实现方案之间的各项指标，可以验证改进措施的有效性，同时确保及时发现并解决任何性能退化的问题。

保持向后兼容性

在迁移过程中，必须确保现有的客户端及集成系统能够继续正常运行。通过提供分版本的API或适配器来维持向后兼容性，就能实现平稳的过渡，而不会影响到用户或其他依赖系统。

何时不应进行迁移

并非所有情况下迁移都是正确的选择。如果某个旧应用程序运行稳定、更新频率很低且能够满足业务需求，那么进行全面迁移可能并不值得投入相应的成本和精力。此外，某些企业级系统还会严重依赖Windows特有的技术或第三方库，而这些技术或库在ASP.NET Core中并没有对应的解决方案。

在以下情况下，应避免立即进行迁移：

• 业务风险高于现代化改造带来的收益

• 该应用程序即将被淘汰或不再需要继续使用

• 某些关键依赖组件在ASP.NET Core中无法得到支持

• 团队缺乏进行测试和代码重构所需的资源

• 迁移可能会导致系统停机或出现不稳定现象，从而严重影响业务运营

在这种情况下，保留现有系统的同时逐步对特定模块进行现代化改造，可能会是更为实际的选择。

未来的改进方向

随着各组织继续使用ASP.NET Core对应用程序进行现代化改造，未来的改进重点将主要集中在可扩展性、自动化程度以及云原生开发实践方面。迁移到ASP.NET Core后，将为采用新的架构模式和基础设施技术奠定基础。

微服务的应用

迁移完成后，许多组织会逐步将庞大的单体系统拆分为微服务。这样做可以提高系统的可扩展性、增强容错能力，并允许各个应用程序组件独立部署，从而加快开发周期。

云原生部署

ASP.NET Core应用程序非常适合在微软Azure、亚马逊Web Services（AWS）和谷歌云等云平台上进行部署。未来的改进措施可能还包括自动扩展功能、无服务器架构以及容器编排服务等内容。

使用Kubernetes进行容器编排

基于容器的ASP.NET Core应用程序可以通过Kubernetes来实现自动化扩展、服务发现以及高可用性管理。这对于企业级分布式系统而言尤为有用。

高级可观测性与监控功能

现代系统越来越多地集成诸如集中式日志记录、分布式追踪和性能监控等功能。Prometheus与Grafana等工具能够帮助团队主动发现存在的问题并优化系统性能。

API网关与服务网格的整合

随着应用程序向分布式架构演进，API网关与服务网格在流量管理、身份认证及安全防护方面发挥了重要作用。这些技术能够提升服务之间的通信效率，同时增强系统的弹性和可治理性。

人工智能辅助的开发与自动化

现代.NET生态系统越来越多地融入了由人工智能驱动的编码助手、自动化测试工具以及智能化的持续集成/持续交付流程。这些技术能够有效缩短开发周期、提升代码质量，并简化迁移后应用程序的长期维护工作。

结论

从ASP.NET Framework迁移到ASP.NET Core MVC是一项具有战略意义的现代化改造举措，而不仅仅是一次技术升级。虽然这一过程会面临诸多挑战——从架构调整到依赖关系处理问题——但长期来看，其带来的收益是显而易见的。

通过采用渐进式迁移策略、利用现代工具，并注重构建清晰合理的系统架构，各组织就能够成功过渡到这样一个专为高性能、可扩展性以及云原生开发而设计的平台之上。

ASP.NET Core不仅仅是.NET技术的未来发展方向，更是我们在当今分布式环境中构建具备强大弹性的现代化应用程序的重要基础。

Related Posts:

• ASP.NET-Core-in-.NET-11-Preview-1版本带来了新的Blazor组件、改进的…
• 如何从“Hello World”程序起步，逐步开发出真正的实际应用程序
• Microsoft-Agent-Framework-RC简化了.NET及Python环境中的代理程序开发过程
• 如何使用 Django Rest Framework 和 Simple JWT…
• .NET 10现已在AWS Lambda上作为托管运行时环境以及基础镜像可供使用。
• .NET 10现已在AWS Lambda上作为托管运行时环境以及基础镜像提供使用。