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 に答える