这个问题的核心是EF Core的迁移历史表（__EFMigrationsHistory）和实际数据库状态不一致：你之前已经成功应用了AddScreens迁移，所以这条迁移的记录已经存在于__EFMigrationsHistory中。当你手动删除Screens表后，再次执行dotnet ef database update AddScreens时，EF会误以为你想要回滚到该迁移之前的状态，尝试运行迁移的Down方法（通常是删除Screens表），但此时表已经不存在，所以抛出找不到对象的错误。

下面是几种可行的解决方案，按推荐程度排序：

方案一：修复迁移历史记录（推荐） #

直接修正__EFMigrationsHistory表，让EF重新执行AddScreens的Up方法：

1. 打开SQL Server管理工具（比如SSMS），找到你的数据库，打开__EFMigrationsHistory表。
2. 找到迁移名称为AddScreens的那条记录，删除它。
3. 回到命令行，执行：

   dotnet ef database update AddScreens
   

   这时候EF会认为AddScreens从未被应用过，会重新运行它的Up方法，自动创建Screens表。

方案二：创建新迁移重建表（适合不想修改历史表的场景） #

如果不想动迁移历史表，可以生成一个新的迁移来重建Screens表：

1. 确保你的实体模型中Screen类的定义是正确的（和之前创建表的结构一致）。
2. 执行命令生成新迁移：

   dotnet ef migrations add RecreateScreensTable
   

   EF会检测到数据库中缺少Screens表，自动在新迁移中添加创建表的语句。
3. 应用新迁移：

   dotnet ef database update
   

方案三：重置整个数据库（仅适合开发环境，会丢失所有数据） #

如果是开发环境且数据不重要，可以直接重置数据库：

1. 删除现有数据库：

   dotnet ef database drop -f
   

2. 重新创建并应用所有迁移：

   dotnet ef database update
   

   这样会从头开始创建所有表，包括Screens。

注意事项 #

• 永远不要手动修改EF Core管理的数据库表结构（除非你清楚迁移历史的影响），尽量通过迁移命令来修改表，避免出现状态不一致的问题。
• 如果是生产环境，优先选择方案一，避免生成冗余迁移，保持迁移历史的清晰。

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