.NET Framework与.NET Core兼容性问题

Question

在迁移现有.NET Framework应用程序至.NET Core时，常见的兼容性问题之一是依赖的第三方库或内部组件不支持跨平台运行。例如，某些NuGet包依赖于Windows特有的API（如WCF服务引用、System.Web或注册表操作），而这些在.NET Core中被移除或重构。此外，项目文件格式差异（.csproj与project.json）导致部分编译指令和依赖项无法直接兼容。开发者常遇到Assembly Resolution失败、配置文件（web.config → appsettings.json）结构变化引发的配置读取异常等问题。如何识别并替换或封装这些不兼容的API，成为平滑迁移的关键挑战。

Answer 1

1. 常见兼容性问题分类与初步识别

在将现有 .NET Framework 应用程序迁移至 .NET Core 时，开发者首先面临的是跨平台兼容性挑战。以下是一些高频出现的不兼容点：

• System.Web 依赖：ASP.NET Web Forms 和传统 MVC 使用的 System.Web.dll 在 .NET Core 中被完全移除。
• Windows 特定 API：如注册表操作（Microsoft.Win32.Registry）、WMI、事件日志等仅限 Windows 的功能。
• WCF 客户端/服务支持有限：.NET Core 对 WCF 的支持为客户端优先，且部分绑定和行为不可用。
• 第三方 NuGet 包不兼容：许多旧包未更新以支持 netstandard 或 netcoreapp 目标框架。
• 项目文件格式差异：从 project.json 到新的 SDK-style .csproj 格式的变化影响依赖解析与构建逻辑。
• 配置系统重构：web.config + ConfigurationManager 被 appsettings.json + Microsoft.Extensions.Configuration 取代。
• Assembly Resolution 失败：由于加载上下文变化，动态加载程序集时常出现 FileNotFoundException。
• GAC 依赖缺失：全局程序集缓存（GAC）在 .NET Core 中不存在，需显式引用所有依赖。
• 代码生成与 T4 模板问题：设计时工具链变更导致模板无法执行。
• COM Interop 不可用：.NET Core 不支持 COM 组件调用，影响 Office 自动化等场景。

2. 分析过程：如何系统性识别不兼容项

为了高效推进迁移工作，必须建立结构化的分析流程。推荐采用“静态扫描 + 动态测试”双轨策略：

1. 使用 dotnet-migrate 工具或 Visual Studio 升级助手进行初步转换。
2. 运行 .NET Portability Analyzer 扫描程序集，生成兼容性报告。
3. 检查编译输出中的警告（如 CS0618 过时 API 调用），定位潜在风险点。
4. 审查 NuGet 包依赖树，确认每个包是否支持 netstandard2.0+ 或 netcoreapp3.1+。
5. 通过 IL Spy 或 ILSpy 分析私有组件内部是否调用了 P/Invoke 或 Win32 API。
6. 启用运行时诊断日志（如 EventListener 或 ILogger），捕获 AssemblyLoadException 等异常。
7. 构建最小可运行示例，逐步集成模块并验证行为一致性。

3. 解决方案路径图

graph TD
    A[开始迁移] --> B{是否存在非跨平台依赖?}
    B -->|是| C[隔离不兼容代码到独立程序集]
    B -->|否| D[直接迁移到 .NET Core]
    C --> E[封装为网关服务或适配层]
    E --> F[通过 HTTP/gRPC 暴露接口]
    F --> G[主应用调用 REST API 替代原生调用]
    C --> H[使用条件编译 #if NETFRAMEWORK / #if NETCOREAPP]
    H --> I[实现多目标构建]
    I --> J[统一 API 表面]
    G --> K[完成解耦迁移]
    J --> K

4. 关键技术替换对照表

.NET Framework 技术	.NET Core 替代方案	注意事项
System.Web.HttpContext	Microsoft.AspNetCore.Http.HttpContext	需引入 ASP.NET Core 中间件模型
Web.config + ConfigurationManager	appsettings.json + IConfiguration	支持多环境配置（Development/Production）
WCF 服务端	gRPC + Protobuf 或 ASP.NET Core Web API	需重构契约与序列化逻辑
Registry.GetValue()	配置文件存储或环境变量	避免持久化敏感数据于注册表
App_Code 编译	预编译类库（.dll）	不再支持运行时编译 .cs 文件
Global.asax Application_Start	Startup.cs 中的 ConfigureServices 和 Configure	依赖注入容器内置集成
FileShare 锁竞争	使用 IFileProvider 抽象	提升跨平台文件访问健壮性

5. 封装与抽象策略实践

对于短期内无法替换的核心组件（如遗留 COM 组件或专有 SDK），应实施“防腐层”（Anti-Corruption Layer）模式：

public interface IUserRepository
{
    Task<User> GetByIdAsync(int id);
}

// .NET Framework 实现（运行在独立进程中）
public class LegacyUserRepository : IUserRepository
{
    public Task<User> GetByIdAsync(int id)
    {
        // 调用旧版 DAL 或 Web Service
        var result = LegacyDataAccess.GetUser(id);
        return Task.FromResult(MapToUser(result));
    }
}

// .NET Core 主应用中通过 HTTP 客户端调用防腐层
public class ApiUserRepository : IUserRepository
{
    private readonly HttpClient _client;
    
    public async Task<User> GetByIdAsync(int id)
    {
        var response = await _client.GetAsync($"/users/{id}");
        return await response.Content.ReadFromJsonAsync<User>();
    }
}

该方式允许新旧系统共存，并为未来彻底重构提供过渡路径。