コードファーストのEntity Framework移行コードをデバッグする

私はWebサイトで最初にEntity Frameworkコードを使用していますが、移行コードをデバッグする方法があるかどうか疑問に思っています。ご存知のように、ブレークポイントの設定などです。

パッケージマネージャーコンソールを使用して、を使用してデータベースを更新していますUpdate-Database。

ありがとう

EF Code First Migrationsは比較的新しいツールですが、まだ.NETを使用していることを忘れないでください。

だからあなたは使うことができます：

if (System.Diagnostics.Debugger.IsAttached == false)
{
    System.Diagnostics.Debugger.Launch();
}

その後、InnerExceptionを確認できます。

または、次のようなtry ... catchステートメントを使用できます： 例外処理エンティティフレームワーク

dbマイグレーションでブレークポイントに到達するには、初期化時にコンテキストをMigrateDatabaseToLatestVersionに設定します。

Database.SetInitializer(new MigrateDatabaseToLatestVersion<EnterContextHere, Configuration>());

次に、通常どおりデバッグ（f5を使用して実行）するだけで、プロジェクトを初めて実行したときにブレークポイントがヒットします。

ここでの問題は、2回目にデバッグを行うと、移行が実行されないことです。これは、__ MigrationHistoryテーブルが更新され、最新バージョンに移行したことが示されているためです。移行を再テストするには、パッケージマネージャーコンソールを開き、以前の移行にダウングレードします。

Update-Database –TargetMigration: ThePreviousMigrationName

私の答えは少しばかげているかもしれませんが、とにかくここに行きます。私と同じように、Seed（）メソッドで問題が発生する場合、私が通常行うことは、Protect Seed（）を呼び出すパブリックメソッドを作成することです。

public void SeedDebug(AppDbContext context)
{
    Seed(context);
}

次に、HomeControllerで、このメソッドをデバッグモードで呼び出します。

public class HomeController : Controller
{
    var appDb = new AppDbContext();
    public ActionResult Index()
    {
        var config = new Configuration();
        config.SeedDebug(appDb);
        return View();
    }
}

私はそれが少し不十分な解決策であることを知っていますが、それはシンプルで迅速です。もちろん、これはモデルの作成後に行う必要があります。だから一歩一歩：

1. シードメソッドをコメント化し、update-databaseを実行してモデルを作成します

2. メソッドSeed（）のコメントを外し、前述の「ハック」をプラグインします。

3. 構成で自動移行を無効にする

   AutomaticMigrationsEnabled = false; //これを無効にしている場合は、すでにこの手順をスキップしてください

4. アプリケーションをデバッグし、エラーを修正して「ハック」を削除します

ここに、大騒ぎせずにトリックを実行する、よりフェイルプルーフな方法があります。

ステップ＃1：次のコードを、デバッグする移行のすぐ上に配置します。

public partial class ORACLE_Test : DbMigration
{
    public override void Up()
    {
        if (!System.Diagnostics.Debugger.IsAttached)
            System.Diagnostics.Debugger.Launch();

        AddColumn("TEST", "UR_USER_ID", x => x.Decimal(nullable: false, precision: 11, scale: 0, storeType: "number"));
        AddColumn("TEST", "UR_CLIENT_ID", x => x.Decimal(nullable: false, precision: 11, scale: 0, storeType: "number"));
        [...]
    }

    public override void Down()
    {
    }
}

ステップ2：移行を含むプロジェクトをコンパイルする

ステップ＃3：移行のDLLを含む出力ディレクトリ（/ bin / Debug、/ bin / Releaseなど）内のコンソールを開きます

ステップ＃4：/ scriptFileパラメーターを指定してmigrate.exeを呼び出し、デバッガーを起動し、実際に目的のdb-migrationをデバッグします

migrate.exe "Your.Migrations.Assembly.dll" /scriptFile="foo.sql" /verbose /startupConfigurationFile="Your.Migrations.Assembly.config"

デバッガーセレクターダイアログがポップアップしたら、既に開いているVisual Studioインスタンスを選択します。

移行コードにConsole.WriteLineステートメントを追加できます（優れたソリューションではありません）

このメッセージは、migrate.exeユーティリティを使用して移行コードを実行した場合にのみ表示されることに注意してください（でpacakges\EntityFramework.x.y.z\tools）。パッケージマネージャーコンソールから移行を実行した場合は表示されません。

私は "Debugger.Launch（）"を使用してたくさんの幸運を手に入れました（上記のm_davidの答えのように））を他の場所で内では、どういうわけか、アタッチすることもアタッチしないこともできます。つまり、.asmファイルと.cppファイル（内部コード）が添付され、ステップインしようとします。私が知っているConsole.Writelineにブレークポイントを設定しようとすると、後で実行されます（「dotnet ef migrations COMMAND」からの出力が表示されます）。それを実行し、ブレークポイントに到達しません。

これは代わりに私のために働いたものです：

while (!System.Diagnostics.Debugger.IsAttached)
    System.Threading.Thread.Sleep(10);

// Breakpoint after this...

あなたは、マイグレーションを実行し、手動でのVisual Studioを使用して添付し、それができます実際に、それはちょうどより多くの痛みのだ、あなたが期待するようにあなたのコードをステップ実行してみましょう。私が実際に試みるべきことは、両方の方法の組み合わせです...

エラーの詳細を取得するための巧妙なトリックもここにありました...

基本的に、トリックは、例外からすべての情報を取得し、それを文字列に入れて、生成された文字列と元の例外とともに新しいDbEntityValidationExceptionをスローすることです。