问题背景 #

我最近在开发第一个基于EF 6.0的后端系统，一开始就踩了命名规范的坑——把.NET和.NET Framework搞混了，引发了一连串问题。我想用代码优先模式自动生成Azure SQL数据库的表，但执行Add-Migration时提示需要先配置文件。当时脑子一热，没仔细区分EF和EF Core的差异，直接全局安装了EF的CLI工具，结果运行dotnet ef migrations script -i时，直接炸出了循环依赖错误。查资料发现大部分迁移教程都是针对.NET Core 6.0的，当时就纠结到底是要把整个项目迁到.NET Core，还是有.NET Framework下的可行方案。

错误详情 #

当时弹出的错误信息是这样的：

(*用户驱动器路径*)\OneDrive\Documents\Visual Studio 2022\Projects\MakrBackend（解决方案根目录，曾重构为Makr-Backend但未更改实际文件夹名）\Makr-Backend（项目）\obj\Makr-Backend.csproj.EntityFrameworkCore.targets(4,5): error MSB4006: 存在涉及目标"GetEFProjectMetadata"的循环依赖关系。[(*用户驱动器路径*)\OneDrive\Documents\Visual Studio 2022\Projects\MakrBackend\Makr-Backend\Makr-Backend.csproj]
无法检索项目元数据。请确保这是SDK风格的项目。如果使用自定义BaseIntermediateOutputPath或MSBuildProjectExtensionsPath值，请使用--msbuildprojectextensionspath选项。

复现步骤 #

1. 打开Visual Studio 2022内置的PowerShell终端
2. 执行命令：dotnet-ef migrations add InitDB
3. 之前已经全局安装了dotnet，执行dotnet-ef能正常显示帮助信息
4. 这里还有个小插曲：之前因为EF的问题多次重建解决方案，最近一次先创建了无连字符的项目，后来把解决方案重命名为Makr-Backend并新建了同名项目，虽然删掉了无连字符的项目，但根目录还留着那个文件夹（因为里面有数据库模型参考图没删）

最终解决方案 & 踩坑总结 #

后来我才搞明白——Entity Framework（EF 6）和Entity Framework Core是完全不同的两个框架，之前的错误根源就是用EF Core专属的dotnet ef CLI工具去操作.NET Framework下的EF 6项目，而.NET Framework的传统项目不是SDK风格的，直接触发了循环依赖的问题。

最后我选择把项目迁移到.NET Core，改用Entity Framework Core，顺利完成了Azure SQL数据库的表生成。这里给大家两个方向的建议：

方向1：坚持用.NET Framework + EF 6

• 别用dotnet ef CLI工具，改用Visual Studio的Package Manager Console（PMC），执行Add-Migration、Update-Database这些EF 6专属命令
• 确保在PMC的"默认项目"下拉框里选中你的数据访问项目
• 一定要在app.config/web.config里配置好连接字符串和EF的相关配置（比如指定数据库提供者）

方向2：迁移到.NET Core/.NET 6+（推荐）

EF Core的生态更活跃，对云服务（比如Azure SQL）的适配更好，CLI工具也更完善。迁移时注意这些点：

• 把项目转换成SDK风格的csproj（.NET Core默认就是这种格式，不用手动改太多）
• 卸载EF 6的NuGet包，安装EF Core相关包：Microsoft.EntityFrameworkCore、Microsoft.EntityFrameworkCore.SqlServer、Microsoft.EntityFrameworkCore.Tools
• 调整DbContext的配置：EF Core里可以通过OnConfiguring方法配置，或者用依赖注入的方式注册
• 重新执行dotnet ef migrations add InitDB生成迁移脚本，再用dotnet ef database update同步到Azure SQL

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