我遇到以下情况：
当我使用Add-Migration [update-name]添加显式迁移时，它会创建一个带有时间戳[now]的文件。 从版本1和版本2升级到版本3，首先进行自动迁移，然后进行显式迁移，只要版本1和版本2已经安装/运行 - 在我的显式迁移的时间戳之前。
据我所知，这是因为使用版本1和2创建的数据库中的AutoMigration条目在我的显式迁移时间戳之前有时间戳，因此EF知道它需要执行我的显式迁移。
但如果在之后安装/运行版本1或2 我创建了显式迁移，比如下个月，我仍然希望用户能够升级到版本3.但是，显式迁移没有触发。我认为，因为第一次运行版本1和2触发的AutoMigrations在为我的手动迁移创建的时间戳之后生成时间戳。
更新
我认为我的问题是我仍需要首先进行自动迁移，然后立即进行我的显式迁移。 需要第一个autoMigration来将数据库从以前的任何自动迁移版本带到版本2的状态（在我的显式迁移之前），然后显式迁移到版本3。 它似乎是＆＃34;时间戳＆＃34;的顺序。那么重要，因为如果数据库中已经有一个具有更高＆＃34;时间戳＆＃34;比我明确的迁移标签， 首先不执行新的自动迁移，迁移失败。如果我使用＆＃34;更高的＆＃34;标记我的显式迁移。时间戳，自动迁移+显式迁移正确执行。
示例 如果我的数据库已经包含过去创建的自动迁移，比如__MigrationHistory中的Id
201610260843258_AutomaticMigration
然后在更新数据库之后，成功更新的表包含：
201610250843258_AutomaticMigration
201610260852133_v891_AutomaticMigration
201610260852134_v891
其中 201610260852134_v891 是我的显式迁移。
然而，如果＆＃34;初始＆＃34;使用＆＃34;时间戳＆＃34;生成自动迁移。将在我的显式迁移ID的前缀之后排序，例如
201610270843258_AutomaticMigration
然后更新数据库失败，因为它不了解它需要先做另一个AutoMigration;所以它只是尝试应用我的显式迁移。
所以我现在的解决方案（或者如果你愿意的话）将从现在开始禁用自动启动，始终创建显式迁移，并手动将其ID重命名为总是排名较高的＆＃34;更高的＆＃34;比任何未来可能已经完成的自动迁移（也就是说，具有生成的Id的自动迁移将高于我的显式迁移）。
如果有人对此解决方法有任何建议或评论，请随意！ ：）