Question

我们希望摆脱100多个迁移类，因为生产中的DB模式是最终的。

以下是我遵循的步骤：

删除迁移文件夹。
添加迁移 - ??

哪些命令行可以帮助我们？

编辑：

如果一切顺利Up（）迁移方法应该是空的吗？对于以下示例是Add-Migration上的错误生成。因为如果我们执行项目我们将得到重复的表错误。

public partial class Sanity : DbMigration
{
    public override void Up()
    {
        CreateTable(
            "dbo.AccountPreferences",
            c => new
            {
                AccountID = c.Guid(nullable: false),
            }
            .... for 1000s of tables
      }
}

干净的迁移是这样的：在后续更改中尝试Add-Migration时，不应该出现任何错误。

无法生成显式迁移，因为以下内容显式迁移待定：[201712281054591_Sanity]。适用在尝试生成新的之前暂挂显式迁移显式迁移。

正如您所看到的，如果我们碰巧执行Update-Database将导致表已存在错误。

我们是否被迫始终保留所有迁移副本？

Answer 1

看看这是否有帮助：

MVC3 and Code First Migrations - "model backing the 'blah' context has changed since the database was created"

Entity framework code first - how to run Update-Database for production database

How to delete and recreate from scratch an existing EF Code First database

注意：
我正在写这个从记忆，如果你有问题让我知道，我会仔细检查。
此外，我对此的了解来自稍微旧版本的EF ，因为我最近没有做太多工作，但我怀疑已经发生了很大变化。

据我所知，如果你想...... a）保持数据库，
b）清理项目迁移，
c）让2'匹配'，同步：

执行以下操作：
- 删除迁移文件夹（您的项目）
- 运行Add-Migration Initial - 然后应添加一个迁移
- 警告：安全但在下一步之前进行备份，更改连接字符串等 - 运行Update-Database -Script - 不更新数据库但创建SQL脚本，包括迁移表
- 找到INSERT INTO [__MigrationHistory]条记录，只需运行它们（在数据库上），将它们插入数据库

...然后再次使用Add-Migration进行测试，看它是否会产生任何结果，不应该产生新的迁移，空的迁移。

请仔细阅读上面的第一个链接，并根据需要调整方法。

我确信可能有更简单，更短的方法（通过PM控制台），但目前还没有意识到这一点。

Answer 2

想知道“最后”会持续多久？

使用：

Add-Migration Initial

删除迁移文件夹后

Answer 3

打开您的数据库。

清除表格__MigrationHistory

删除文件夹中的迁移

运行Add-Migration MigrationName

Answer 4

几乎与已接受的相同，但是没有脚本编写初始迁移。

删除__MigrationHistory数据库表
删除“迁移”文件夹中的所有迁移文件
在程序包管理器控制台中运行Add-migration Initial
在初始迁移中注释掉Up方法内部的代码
在PM控制台中运行Update-database（仅用于创建迁移条目）
在初始迁移中删除评论

如何清理＆amp;为现有数据库生成新的迁移？

4 个答案: