.NET旧类库项目分阶段升级相关技术咨询

首先可以明确告诉你：分阶段升级的思路完全可行，而且是非常稳妥的选择，完全没必要一开始就考虑重写。我帮你梳理下具体的步骤和注意事项：

第一步：先把.NET 4.7类库转为SDK-style项目 #

SDK-style项目并不是.NET Core/.NET 5+专属的，.NET Framework也支持这种项目格式，而且这一步完全兼容原有.NET 4.7代码。这么做的好处是：

• 项目文件会变得简洁很多，不再是原来冗长的格式，更容易维护
• 可以用PackageReference替代老旧的packages.config管理第三方依赖，对后续升级第三方库友好太多，也能避免很多依赖冲突问题
• 为后续升级到.NET 6做好铺垫，因为SDK-style是新框架的标准项目格式

实操的时候不用一次性改完整个大项目，你可以挑一个相对独立的子模块先动手：

1. 备份原项目的.csproj文件，以防出问题能快速回滚
2. 把原.csproj内容替换成SDK-style的基础结构：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net47</TargetFramework>
  </PropertyGroup>
  <!-- 这里添加原项目的引用、NuGet包等 -->
</Project>

3. 用Visual Studio自带的工具把packages.config迁移到PackageReference（右键项目→管理NuGet包→右上角设置按钮→选择“迁移到PackageReference”），工具会自动处理大部分依赖
4. 编译测试，处理可能的小问题（比如一些特殊的COM引用或者项目引用需要手动调整）

等第一个模块跑通了，再逐步推进其他模块，这样风险非常小。

第二步：在SDK-style的.NET 4.7项目中逐步替换ADO.NET为Entity Framework #

这一步也不用全量替换，建议从小的、低风险的业务模块入手：

• 先选择EF 6（而不是直接上EF Core），因为EF 6完美兼容.NET 4.7，和现有代码的适配成本更低，而且它的API和EF Core有不少相似之处，后续再迁到EF Core会更平滑
• 针对每个模块，先给原有ADO.NET的逻辑写好单元测试，确保替换后的EF代码功能完全一致
• 慢慢把原来的SQL查询、DataTable等逻辑替换成EF的DbContext、实体类，每次只改一部分，测试稳定后再继续

这样做的好处是，你可以在不影响现有系统运行的前提下，逐步把旧的ADO.NET代码替换成更现代的ORM实现，同时熟悉EF的使用方式。

第三步：时机成熟后升级到.NET 6 #

等大部分EF 6的代码都稳定了，第三方库也都确认有.NET 6兼容版本（或者有合适的替代方案），就可以开始升级到.NET 6了：

• 把项目的TargetFramework从net47改成net6.0
• 把EF 6替换成EF Core（EF 6在.NET 6上虽然能运行，但官方更推荐用EF Core，而且EF Core对新框架的支持更好），这一步因为之前已经用了EF的思想，迁移成本会比从ADO.NET直接迁EF Core小很多
• 逐个处理第三方库的兼容性：升级到支持.NET 6的版本，没有兼容版本的话，评估是否可以用其他库替代，或者是否有兼容的 workaround
• 处理代码中的过时API替换，比如一些.NET Framework专属的类需要换成.NET 6中的替代实现

同样，这一步也可以分模块推进，先升级核心模块，测试没问题再扩展到其他部分。

关于升级还是重写的选择 #

从你的描述来看，完全没必要选择重写。重写通常是在原有架构彻底无法维护、技术债务到了无法挽回的地步才考虑的方案，而你的情况是可以通过分阶段升级逐步迭代的，既能保留现有业务逻辑的稳定性，又能逐步过渡到新技术栈，风险和成本都比重写低太多。

备注：内容来源于stack exchange，提问作者Computer