9

EF を使用しない製品にコードベースの EF 移行を使用して調査しています。次のコマンドを除いて、すべてが一般的にうまく機能します。

Add-Migration MyTestMigration

次のメッセージを出力します。

次の明示的な移行が保留中のため、明示的な移行を生成できません: [201206260845338_DannyTest]。新しい明示的な移行を生成する前に、保留中の明示的な移行を適用してください。

この理由は、接続文字列がビルド時に不明であり、EF が .\SQLExpress に "MyContextName" というデータベースをランダムに作成したためです。このデータベースに存在しないデータベース テーブルを参照しているため、保留中の移行を適用できません。スクリプトを実行する方法として移行を使用しようとしているだけです。

質問は次のとおりです。

  1. 自動移行を使用していない場合 (EnableAutomaticMigrations=false を使用)、生成された (空の) 移行にまったく影響がないにもかかわらずAdd-Migration、データベースが最新である必要があるのはなぜですか? 私は、MS がこのユース ケースを意図していないとは信じがたいと思います。唯一の「壊れた」ものは、​​動作に影響を与えない検証です。

  2. これを回避する方法はありますか?独自の Add-Migration コマンドを作成して、EF の機能を複製するだけで、(一見不必要な) DB の最新チェックをスキップしますか? さまざまな引数を渡そうとしましたが、これまでのところ機能させることができませんでした。

編集：

私は実際にこの問題を解決するためのより良い方法を見つけましたが、実際にはこれらの質問に対する答えではないので、ここに追加します. うまくいけば、これをブログ投稿に変える時間ができます!

私が Add-Migration を使用したかった唯一の理由は、DbMigration に伴うすべての問題のためでした。しかし、基本クラスを使用すると、基本クラスに属性から移行 ID を自動生成させることで、基本的にこれらすべての必要性を排除できることに気付きました。モデルの状態は変わらないため、ターゲットはすべての移行で同一です。ここで、次のように移行を手動で作成します (日付は、EF が正しい順序で適用されるように ID を作成するために必要です)。

[Migration(2012, 6, 27, 12, 00, "Add new xxx fields for yyy")]
internal class MyNewMigration : MyDbMigration
{
    public override Up()
    {
        // ...
    }
    public override Down()
    {
        // ...
    }
}

このMyDbMigrationクラスには、Target/Source/Id プロパティがあります。Target はハードコーディングされており (最初の移行で Add-Migration が作成した値と同じ)、Source は null であり、Id は MigrationAttribute を読み取るリフレクションです。これは、これらのクラスを手動で作成できるようになったことを意味します。IMigrationMetadata のすべてについて心配する必要はありません:-)

4

2 に答える 2

1

既存の移行 (.\SQLExpress で作成されたデータベースに適用されていない移行) をコメントアウトして、アプリを再実行してみてください。これにより、必要な初期テーブルがローカル データベースに入力されます。

ローカル データベースが正しい構造になったら、移行のコメントを解除し、update-database を使用してローカル データベースを最新の状態にします。その後、新しい移行を追加できます。

また、update-database コマンドに -connectionString パラメーターがあることを覚えておいてください。これにより、特定のサーバー/データベースで移行をターゲットにすることができます。

于 2012-06-27T06:17:42.523 に答える