.NET Core 3.1应用如何复用带EF6.4和Oracle托管EF驱动的.NET4.7.2类库？

现有方案可行性结论 #

你当前尝试的.NET Standard 2.1多目标适配方案不建议用于生产环境：

• Oracle.ManagedDataAccess.EntityFramework的.NET Framework版本内部调用了大量.NET Framework专属API（包括传统配置体系、System.EnterpriseServices事务组件等），并不完全符合.NET Standard 2.1的API约束
• 压制NU1702警告后编译可以通过，但运行时大概率出现类型加载失败、配置不生效等异常，尤其在事务处理、EF provider注册场景下问题尤为明显

可行的替代方案 #

方案1：类库直接多目标适配两端框架（代码改动量小） #

放弃.NET Standard中转，直接让类库同时面向.NET Framework 4.7.2和.NET Core 3.1两个目标框架，通过条件引用适配不同平台的Oracle驱动：

1. 修改类库的csproj文件，替换单目标框架声明为多目标：

<TargetFrameworks>net472;netcoreapp3.1</TargetFrameworks>

2. 按目标框架条件引用对应依赖包：

<!-- 公共依赖EF 6.4 -->
<PackageReference Include="EntityFramework" Version="6.4.4" />
<!-- .NET Framework 端用传统Oracle EF驱动 -->
<PackageReference Condition="'$(TargetFramework)' == 'net472'" Include="Oracle.ManagedDataAccess.EntityFramework" Version="19.3.0" />
<!-- .NET Core 端用Oracle官方EF6兼容的Core驱动，注意版本要和EF 6.4匹配 -->
<PackageReference Condition="'$(TargetFramework)' == 'netcoreapp3.1'" Include="Oracle.ManagedDataAccess.EntityFrameworkCore" Version="6.21.100" />

3. 少量条件编译适配两端配置逻辑差异即可，原有EF业务代码几乎不需要改动。

方案2：服务化封装（零代码改造旧类库） #

如果不想修改原有类库的任何代码，可以将该数据访问类库封装为独立的gRPC/HTTP服务，部署后由.NET 4.7.2 OWIN应用和.NET Core 3.1应用分别调用，完全规避框架版本兼容问题。

方案3：迁移到EF Core（长期维护最优） #

如果后续计划长期迭代该类库，可以将EF 6.4代码迁移到EF Core，Oracle官方的Oracle.EntityFrameworkCore包原生支持.NET Standard，后续可以同时适配所有.NET平台。

临时测试验证方案 #

如果仅需要快速验证功能，可以在csproj的PropertyGroup节点中加入以下配置压制NU1702警告，仅用于测试场景，禁止生产环境使用：

<NoWarn>NU1702</NoWarn>

内容的提问来源于stack exchange，提问作者AunAun