Question

让我分解一下情景：

我使用代码优先方法
我为MigrateDatabaseToLatestVersion
我使用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使用相同的命名空间？

Answer 1

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

当我在配置文件，迁移文件和迁移设计器文件之间设置相同的命名空间时，一切都运行良好，我可以随时更改命名空间，而EF不会丢失旧迁移。

如果更改项目名称空间，是否可以让Entity Framework识别以前的迁移？

1 个答案: