4

让我分解一下场景：

  1. 我使用代码优先方法创建我的模型/映射

  2. 我为MigrateDatabaseToLatestVersion

  3. 我使用创建迁移add-migration

这会创建一个Configuration像这样的类：

namespace MyApp.Migrations
{
    internal sealed class ConfigurationInfo : DbMigrationsConfiguration<MyContext>
    {
    }
}

我可以运行我的代码，数据库将毫无问题地自动创建。

现在我进入并更改我的Configuration班级所在的命名空间：

namespace MyApp.Data.Migrations // <-- new namespace
{
    internal sealed class ConfigurationInfo : DbMigrationsConfiguration<MyContext>
    {
    }
}

我删除数据库并重新运行代码。我现在收到这条消息：

无法更新数据库以匹配当前模型，因为存在待处理的更改并且自动迁移已禁用。将挂起的模型更改写入基于代码的迁移或启用自动迁移。将 DbMigrationsConfiguration.AutomaticMigrationsEnabled 设置为 true 以启用自动迁移。

当我重命名Configuration位于它下面的命名空间时，它不再识别以前创建的任何迁移。

我做了很多实验，当我MigrationsNamespace在构造函数中设置等于旧值时，Configuration如下所示：

    namespace MyApp.Data.Migrations
{
    internal sealed class ConfigurationInfo : DbMigrationsConfiguration<MyContext>
    {
        public ConfigurationInfo()
        {
            AutomaticMigrationsEnabled = false;
            MigrationsNamespace = "MyApp.Migrations"; // <-- this works
        }
    }
}

现在一切正常，除了之前创建的所有迁移都需要在旧命名空间下才能工作，以及所有未来的迁移（它们会自动获取旧命名空间）。

这种解决方法并没有真正做到我想做的事情，它能够重构我的代码并且仍然让实体框架识别我以前的迁移。

如果我的项目名称发生更改，但我有多个安装依赖于 MigrateDatabaseToLatestVersion 数据库初始化程序来接收对我的代码的架构更改，该怎么办？

启用迁移后，我是否被锁定为我的 DAL 使用相同的命名空间？

4

1 回答 1

4

这是我自己的错，我手动进行了重构，并认为我已经更改了项目中所有文件的命名空间，但是我忘记扩展迁移文件并更新“设计器”文件！

当我在配置文件、迁移文件和迁移设计器文件之间设置相同的命名空间时，一切正常，我可以随时更改命名空间，而 EF 不会丢失旧迁移的踪迹。

于 2012-05-31T13:58:59.627 回答