web-dev-qa-db-ja.com

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

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

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

ありがとう

entity-frameworkef-code-firstentity-framework-5ef-migrations
127
Daniel

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

以下を使用できます。

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

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

または、次のようなtry ... catchステートメントを使用できます。 Exception Framework Entity Framework

242
m_david

Db移行でブレークポイントに到達するには、初期化時にコンテキストをMigrateDatabaseToLatestVersionに設定します。

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

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

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

Update-Database –TargetMigration: ThePreviousMigrationName
11
robasaurus

私の答えは少しばかげているかもしれませんが、とにかくここに行きます。私のように、時々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. アプリケーションをデバッグし、エラーを修正して「ハック」を削除します

8
Rui Lima

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

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

4
Tom Ferguson

以下に、大したことなくトリックを実行する、よりフェイルプルーフな方法を示します。

ステップ＃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インスタンスを選択します。

3
XDS

私は「Debugger.Launch（）」（上記の m_david's answer のような）を使って運が良かったのですが、CreateDbContextの内部では、アタッチではなくアタッチではないようです。つまり、添付され、.asmファイルと.cppファイル（内部コード）にステップインしようとします。後で実行されるConsole.Writelineにブレークポイントを設定しようとすると（「dotnet ef migrations COMMAND」の出力を確認できます）、実行され、ブレークポイントに到達することはありません。

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

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

// Breakpoint after this...

移行を実行し、Visual Studioを使用して手動でアタッチすると、で実際にコードをステップ実行できます。私が本当に試すべきことは、両方の方法の組み合わせです...

2
Brent Rittenhouse

また、きれいなトリックを見つけました here エラーの詳細を取得する...

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

0
ghigad