Azure环境下EF DbContext数据库迁移失败的解决方法问询

先搞定"Apply Migrations"按钮路径不存在的问题 #

• ASP.NET Core 8默认不会自动添加迁移应用的端点，得在Program.cs里手动配置（如果是MVC项目，确保路由能匹配上）：

  if (app.Environment.IsDevelopment())
  {
      app.UseMigrationsEndPoint();
  }
  

  注意：生产环境别直接开这个端点，有安全风险，自动化迁移才是正道。

修复GitHub Action里dotnet ef database update报项目文件不存在的问题 #

• 检查工作目录：如果你的项目不在仓库根目录，得先切到项目文件夹再执行命令。比如项目在src/MyWebApp下，Action步骤要这么写：

  - name: 执行EF迁移
    working-directory: ./src/MyWebApp
    run: dotnet ef database update --connection "${{ secrets.AZURE_SQL_CONNECTION_STRING }}"
  

• 先装EF Core工具：GitHub Action环境里默认可能没装，加个安装步骤：

  - name: 安装EF Core CLI工具
    run: dotnet tool install --global dotnet-ef
  

• 确认连接字符串：从Azure门户拿完整的SQL连接字符串，包含服务器地址、数据库名、用户名密码，存在GitHub Secrets里，别硬写在代码里。

替代方案：预生成迁移脚本再部署执行 #

• 用Package Manager Console生成全量迁移脚本（包含Identity的初始表结构）：

  Script-Migration -From 0 -Output ./migrations-script.sql
  

• 把生成的SQL脚本提交到仓库，然后在GitHub Action里用sqlcmd执行：

  - name: 执行迁移脚本
    run: |
      sqlcmd -S "${{ secrets.AZURE_SQL_SERVER }}" -d "${{ secrets.AZURE_SQL_DATABASE }}" -U "${{ secrets.AZURE_SQL_USERNAME }}" -P "${{ secrets.AZURE_SQL_PASSWORD }}" -i ./migrations-script.sql
  

  这个方法更可控，生产环境用着更放心，不用依赖EF Core CLI的环境配置。

检查Azure SQL DB的权限和防火墙 #

• 确保执行迁移的账号（不管是App Service的还是GitHub Action用的）有db_owner权限，至少得有创建表、修改schema的权限。
• 检查SQL Server的防火墙规则，把GitHub Action的IP范围或者Azure App Service的出站IP加进去，不然连不上数据库也白搭。

应急手动迁移 #

• 如果自动化流程暂时搞不定，就在本地用Azure SQL的连接字符串直接执行迁移：

  dotnet ef database update --connection "你的Azure SQL完整连接字符串"
  

  执行前要保证本地的迁移文件和仓库里的完全一致，不然容易出版本冲突。

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