SCMの下にプロジェクトがあります。自分のマシンからビルドし、msdeployを介してリモートサーバーに公開すると、すべてが正常に機能します。

私の同僚が、リモートサーバーエンティティフレームワーク4.3.1で、SCMから新たにプルされた同じプロジェクトで同じことを試みると、次のようになりますDbMigrator。

自動移行は、データが失われる可能性があるため、適用されませんでした。

結局のところ、リモートサーバーに最初に公開したのは「勝者」のようです。データベースをリモートサーバーにドロップすると、同僚が公開でき、ロックアウトされます。私の出版物は上記と同じエラーになります。

の構成は次のDbMigratorようになります。

__MigrationHistoryこれは、新しいテーブルと、その行に格納されている厄介な長い16進文字列と関係があると思います。

私は、出版するために全責任を負いたくありません。何に気をつければいいですか？

エンティティ フレームワークを自動移行で動作させる方法が少しわかりません。私が欲しい：

• 存在しない場合に自動的に作成されるデータベース
• 機種変更時に自動更新するデータベース

後者については、DbMigrator を使用しています。かなり遅いので、リクエストごとに実行したくありません。また、同じアプリケーションに複数のデータベースがあるため、Application_Start に入れることができないため、次のように Session_Start に入れます。

これが正しい方法かどうかはわかりませんが、機能しているように見えますが、データベースが存在しない場合、実際にはデータベースを生成しません。「ログインによって要求されたデータベース「db」を開けません」というメッセージが表示されます

以前は次のように機能していました。

これはデータベースを削除し、データベースが存在しない場合に適したシード データを生成しますが、データベースが変更された場合にもトリガーされます (この場合、DbMigrator で処理する必要があります)。これは前に Application_Start にありましたが、よくわかりませんそれをどうするか。DbMigrator と競合するのではないかと心配しています。前述の 2 つのことを達成するには、どのように設定すればよいでしょうか?

クラスを使用してDbMigrator、保留中の移行のリストを取得しています。何らかの理由で、保留中の移行があるにもかかわらず、アイテムが返されません。私はステップを逃していますか？

接続文字列かもしれないと思いましたが、興味深いのはmigrator.GetDatabaseMigrations()、データベースに既に適用されている移行の正しいリストを返すことです。

PowerShell コマンドを使用する代わりに、コードで DbMigrator を使用して移行ファイルを追加することは可能ですか?

必要なパラメーターなしのコンストラクターのベースに名前または接続文字列をハードコーディングせずに、EF の移行を機能させるにはどうすればよいでしょうか?

EF の移行により、デフォルトのコンストラクターをカスタム dbcontext に追加する必要があります。dbcontext のベースで、nameorconnectionstring を指定する必要があります。

コンストラクターをハードコーディングする必要があるという事実は、クライアント アプリケーションでは構成ファイルなしで動作し、多くの異なるデータベース (サーバー、ローカル SQL コンパクト) に接続しているため、接続を動的に構築するため、処理できないものです。

DbMigrationsConfiguration クラスを調査した後、コンストラクターで設定できる TargetDatabase という名前の DbConnectionsInfo プロパティを見つけました。しかし、この解決策でさえうまくいきませんでした。これは私がしたことです：

最終的に Activator.CreateInstance が DbMigrator 内で使用されることがわかり、このクラスから TargetDatabase.Create などを使用することを期待していました。

ヘルプやフィードバックは大歓迎です。

前もって感謝します、

ウィルコ

DbMigrator の仕組み

新しいインスタンスを作成するコードがありますDbMigrator(new Configuration())

Configurationは のカスタム拡張でDbMigrationsConfiguration<T>、T はDbContext

したがって、 内Configurationには、 と等しい ContextType があり<T>ます。

DbMigrator がインスタンス化されると、DbContext のインスタンスを作成しようとします<T>。コンテキストで空のコンストラクターを使用しようとするか、ジェネリック T ではなく の実際の型であるwhere<T>の実装を探しようとします。IDbContextFactory<...>...

DbMigrator が機能しない理由

問題は、インスタンス化するアセンブリが、検出する必要がDbMigratorある特定の型にアクセスできないことです。IDbContextFactory<...>また、私のDbContextにはデフォルトのコンストラクターがなく、そうしたくありません。だから私は例外を受け取りますThe target context '...' is not constructible.

私を悩ませているのは、私がインスタンス化している時点で、私はすでに移行中のインスタンスDbMigratorを持っている (またはすでにインスタンス内にある可能性がある)ことです。また、 DbMigrator の内部では検出できないジェネリックにアクセスできますが、喜んでインスタンスを提供します。DbContextIDbContextFactory<T>

質問

では、Context インスタンスのみを使用するか、指定した IDbContextFactory のインスタンスを使用するように DbMigrator に指示するにはどうすればよいでしょうか。舞台裏の魔法のジュジュに依存してこれらのものを発見しようとすると（おそらくリフレクション/ ServiceLocationを使用して）、失敗しています。

私の状況

1 つの AppDomain 内で、nコンテキストを使用しています。1 つと言いたいところですが、通常は 2 つです。それ以上になることもあります。したがって、単一のアプリ/Web 構成プロパティ、または単一のDbConfiguration または ConnectionFactoryを指す属性デコレーターに依存するソリューションは、私にとってはうまくいきません。AppDomain ごとに 1 つしか存在できないため、その時点で必要なコンテキストに基づいて構成できない限り、無駄です。そこには小刻みに動く余地がありますが、私にはわかりません。

baseまた、コンストラクターに関連するEFについて、私が理解していないjujuがあるかもしれません。DbConnectionしかし、 a の代わりに a をコンストラクターに渡すとうまくいくとは思いませんnameOrConnectionString。まだ空のコンストラクターではありません。しかし、それを使用してコンストラクターを検索するためにEFが行うこと、およびそれを利用する方法があれば、それはうまくいくかもしれません。