Question

我有使用最近创建的数据库的本地实例DbContext.Database.Create()，所以__MigrationHistory表与InitalCreate输入，该代码的时刻匹配存在。

但是，迁移文件夹中存在一些基于代码的迁移。这些将在我们的开发和登台环境中运行，以使这些数据库与代码保持一致。但是，我不需要在本地应用它们，因为我使用当前代码创建了数据库。

我现在需要对模型进行更改并创建相应的迁移。但是当我运行Add-Migration TestMigration时，我收到以下错误

Unable to generate an explicit migration because the following explicit 
migrations are pending: 

[201203271113060_AddTableX, 
 201203290856574_AlterColumnY]

Apply the pending explicit migrations before attempting to generate 
a new explicit migration.

在这种情况下我该怎么办？我不能将Add-Migration工具指向另一个环境，因为它不能保证版本与我本地的版本匹配。我希望迁移只匹配我所做的更改。

似乎我有一些选择，但没有一个是理想的：

从“迁移”文件夹中删除其他迁移，运行“添加迁移”命令，升级数据库，然后恢复旧迁移。这很简单，但似乎有点ha ..
恢复应用第一次迁移的源代码管理中的模型版本，然后构建它并使用它来创建数据库。然后获取最新版本，应用所有迁移，然后我就可以添加迁移了。这似乎付出了很多努力！
手动创建迁移。

有没有人对如何管理这个有任何建议？

Answer 1

我们计划使用您的选项＃1的变体...

我们的标准操作程序是为每次迁移生成一个SQL脚本（使用update-database的-script选项），以便通过InstallShield将SQL脚本应用于最终用户“生产”数据库（我们计划仅为开发人员数据库使用EF update-database。

因此，我们在Migrations文件夹中为迁移提供了迁移.cs文件和相应的.sql文件。

因此，我们不是从Migrations文件夹中删除迁移（正如您在＃1中提出的那样），而是使用SQL Mgmt Studio手动仅将执行插入的.sql文件部分应用到_MigrationHistory中。

这使本地数据库的_MigrationHistory与已经合并到该数据库中的更改保持同步。

但这是一个问题，我们仍然在寻找更好的解决方案。

DadCat

Answer 2

我发现最有效的方法非常简单：启用迁移后请勿使用DbContext.Database.Create()。如果要以编程方式创建新数据库，请改用迁移API。

var migrator = new DbMigrator(new Configuration());
migrator.Update();

然后您已获得完整的迁移历史记录，并且添加进一步的迁移工作正如预期一样。

Answer 3

我遇到了同样的问题。如果你运行

Update-database

然后运行

Add-Migration YourMigrationName

这解决了问题

Answer 4

只需从解决方案文件中排除旧的迁移文件即可。

使EF4.3代码优先迁移忽略挂起的迁移

4 个答案: