Debug code-first Entity Framework migration codes

Question

I know that EF Code First Migrations is relatively new tool but don't forget about you are still in .NET.

So you can use:

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

After that you can see your InnerException.

Or you can use try...catch statement like this: Exception handling Entity Framework

To hit a break point in a db migration set the context to MigrateDatabaseToLatestVersion on initialise.

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

Then you just debug as normal (run using f5) and the breakpoint will hit the first time you run the project.

The problem now is that if you debug a second time the migration will not run. This is because the __MigrationHistory table has been updated to say you have migrated to the latest version. To re-test the migration open the package manager console and downgrade to the previous migration:

Update-Database –TargetMigration: ThePreviousMigrationName

My answer might be a bit silly but anyway here it goes. If you, like me, some times have problems in the Seed() method what I usually do is simply create a public method that calls the Protect Seed().

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

then in my HomeController I call this method in Debug mode.

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

I know it's a bit lame solution, but it's simple and quick. Of course this has to be done after the model been created. So step by step:

1. comment the seed method and execute the update-database to create the model

2. uncomment the method Seed() and plugin the "hack" I mentioned above.

3. in the configuration disable Auto migrations

   AutomaticMigrationsEnabled = false;//if you have this disabled already skip this step

4. Debug your application, fix the error and remove the "hack"

Here's a more fail-proof method which will do the trick without much fuss:

Step#1: Place this piece of code right above the migration you want to debug:

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()
    {
    }
}

Step#2: Compile the project containing your migrations

Step#3: Open a console inside the output directory (/bin/Debug, /bin/Release etc) containing the dll of your migrations

Step#4: Invoke migrate.exe with the /scriptFile parameter to launch the debugger and actually debug the desired db-migration

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

Once the debugger-selector dialog pops up pick the visual studio instance that you have already opened.

You could add Console.WriteLine statements to the migration code (not a great solution)

Note, the messages are only shown if you run the migration code using the migrate.exe utility (in pacakges\EntityFramework.x.y.z\tools). They will not display if you run the migration through the Package Manager console.

I've had lots of luck using "Debugger.Launch()" (like in m_david's answer above) elsewhere, but inside of CreateDbContext it seems to somehow both attach, and not attach. What I mean is, it attaches and starts trying to step into .asm files and .cpp files (internal code). If I try to set a breakpoint on a Console.Writeline that I KNOW gets executed afterwards (I can see the output from ANY "dotnet ef migrations COMMAND") it both executes it and never hits the breakpoint.

This is what worked for me instead:

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

// Breakpoint after this...

You can execute the migration and manually attach using Visual Studio and it will actually let you step through the code like you expect, it's just more of a pain. What I should really try is the combination of both methods...