Question

我使用ADO.NET实体数据模型创建了我的模型（并从数据库中选择了Code First），因为我在一个已经存在的数据库上创建了一个项目并且一切正常，我能够访问数据库中的数据。但是，我尝试通过为继承自DbContext的类创建数据访问层命名空间来重新排列我的命名空间。但是，当我这样做时，当我尝试使用完全相同的代码时，我得到InvalidOperationException未处理的错误，否则说：The model backing the 'RaaSDbContext' context has changed since the database was created. Consider using Code First Migrations to update the database。有谁知道为什么会这样？我没有改变类的值或其他任何东西（字面意思只是命名空间），所以不知道为什么它不再起作用。

之前的代码：

namespace MyProject.Model
{
    using System.Data.Entity;

    public partial class MyDbContext : DbContext
    {
        public MyDbContext ()
            : base("name=MyConnection")
        {
        }

        public virtual DbSet<MyClass> MyClass{ get; set; }
        etc...
    }
}

代码更改仅在第一行：

namespace MyProject.DAL

调用db的代码：

using MyProject.DAL; //This line was also added on the code change
using MyProject.Model;
etc...
MyDbContext DBContext = new MyDbContext();
List<string> myStrings = DBContext.MyClass
            .Select(a => a.myStrings)
            .ToList();

Answer 1

当您运行迁移时，Entity Framework会创建一个名为 ___ MigrationHistory 的表。在此表中，当您在上下文中进行一些更改时，EF会包含所有需要更新的内容。

因此我们有迁移命令。要了解有关迁移命令的更多信息，请follow this link

在此_MigrationHistory表中，EF还将名称空间作为contextkey列。因此，如果您在命名空间中进行更改，那么您还应该管理这些内容。

请参考this link

因此，在这些情况下，您有两个选择前进

a）运行Sql命令

UPDATE [dbo].[__MigrationHistory]
   SET [ContextKey] = ‘New_Namespace.Migrations.Configuration’
 WHERE [ContextKey] = ‘Old_Namespace.Migrations.Configuration’

b）在这一点上你应该是金，但是，如果你正在与开发团队进行持续集成，或者你有一个持续的部署策略，这将不起作用。为此，解决方案在于将以下代码添加到数据库配置构造函数类：

public Configuration()
{
    AutomaticMigrationsEnabled = false;
    this.ContextKey = “Old_Namespace.Migrations.Configuration”;
}

部分解决方案取自here

Answer 2

我希望我是对的，但我认为你不应该自己修改命名空间。您永远不应该自己修改这些自动生成的文件。

但我认为有一个选择可以满足您的需求：have a look at this example

您应该修改自定义工具命名空间。希望它有效！

更改我的DbContext继承类的命名空间会导致无效的OperationException。为什么？

2 个答案: