【发布时间】：2017-07-31 08:26:01
【问题描述】：
我们自动构建过程的一部分涉及运行 migrate.exe 以将测试数据库更新到最新版本的数据库。
过程比较简单：
- 将migrate.exe复制到正在编译的项目的/bin文件夹中
- 使用连接字符串（在构建定义中指定）执行 migrate.exe。
第二步的一个例子（显然是经过编辑的）是：
migrate.exe Company.Data.dll /connectionString="Server=...;Database=...;User Id=...;Password=..."
/connectionProviderName="System.Data.SqlClient"
其中 Company.Data.dll 是正在构建服务器上编译的项目的刚刚构建的输出。
这个过程已经实施了几个月并且运行良好。直到今天。
今天，当上述命令运行时，migrate.exe 会尝试运行所有迁移 - 从头开始 - 而不仅仅是添加的新迁移。这显然失败了，因为它试图创建数据库中已经存在的表。无论是否实际存在待处理的迁移，都会出现问题。
我已经确认日志文件中显示的连接字符串指向的数据库是正确的，并且它在 __MigrationHistory 表中具有所有适当的条目，这些条目应该会导致迁移只输入缺少的内容。
如果我从源代码管理中提取代码，构建它并自己在本地运行 migrate.exe（使用相同的连接字符串）它会适当地运行（最初只运行它应该运行的迁移，然后在随后的尝试中说没有待处理显式迁移）。
在我看来，只要连接字符串指向正确的数据库并且用于 EF 的 DbContext 派生类的名称与 __MigrationHistory 表中的名称匹配，那么 migrate.exe 应该能够找到条目而不运行这些迁移。
我还缺少什么我应该看的？
更新： 当指向同一服务器上的不同数据库时，我刚刚发生了这种情况。相同的“解决方法”（在本地运行 migrate.exe）。有趣的是，当指向不同的数据库时，它的发生方式完全相同。
【问题讨论】：
-
你的测试数据库是什么？ SQL Server 2008？
-
这很奇怪。我知道 EF 迁移有时会在 2008 年出现这种情况。通常删除和重新创建数据库会有所帮助，但这是一个蛮力解决方案。
-
让我感到沮丧的是，在本地对同一个数据库运行命令可以正常工作。所以我的机器和构建服务器之间肯定有区别......我只是不知道它可能是什么
-
是的，我有，只是在 Azure SQL 中没有。它有效，直到它不起作用。然后没有什么可以使它起作用。我已经花了足够的时间研究迁移 (tech.trailmax.info/2014/03/inside_of_ef_migrations)，只是将其称为一个神奇的故障并继续进行数据库重建。它不会经常发生，但是当它发生时，我从来不知道为什么（stackoverflow.com/q/22648805/809357）-（
标签： c# entity-framework entity-framework-migrations