Entity Framework 5 expects CreatedOn column from MigrationHistory table

Question

I am migrating an MVC 3 application from EF 4.3 to EF 5. I noticed that EF 5 expects a CreatedOn column in the __MigrationHistory table, which does not exist as the migrations were created by an older version.

SELECT TOP (1) 
[c].[CreatedOn] AS [CreatedOn]
FROM [dbo].[__MigrationHistory] AS [c]

How do I resolve this issue without wiping my migration history? I am thinking of a query to infer the column's value from the migration name, which is in the following format:

201203111201542_MigrationName

Creuse

This appears to be a conflict with MiniProfiler: community.miniprofiler.com/permalinks/99/… – Creuse

Answer 1

The CreatedOn column is no longer required. We attempt to query from it in order to determine whether we need to drop it. i.e. You are upgrading from 4.3 to 5.

Catalogue

I don't see how this answers the original question - 'how do i resolve...' – Tourneur

@SpongeMan: I was getting this exception, but it turned out I had accidentally left Visual Studio set up to break on all exceptions, not just unhandled ones. So while Andrew didn't say it explicitly, the resolution is to turn off breaking on first-chance exceptions. Debug->Exceptions, then un-check the Thrown column. – Parenteau

Answer 2

Just like Filip Cornelissen said, it is a thing between MiniProfiler.EF and Entity Framework 5.0.

Solving/hiding the problem is actually easier than you would think. It is only a "debugging problem" as the error you'll get is only happening during the instantiating period (checking for new migrations), and the error is an "SQL Unhandeld Exception".

So, solving this problem is easy:

Go in Visual Studio to your "DEBUG" tab. Hit the "Exceptions" item. In the new dialog, you open the tree "Common Language Runtime Exceptions". Under "System.Data.SqlClient, uncheck both checkboxes after "System.Data.SqlClient.SqlException". Add it, if it ain't there.

And off ya go!

Atavism

Yes it will. But as far as I know, EF doesn't throw (unhandled) SQL Exceptions. So it's pretty safe to ignore those exceptions in your EF powered projects. – Atavism

Answer 3

Seems like a thing in EF Code first with migrations enabled, when you upgrade from EF4.* to EF 5.0. And that in combination with MiniProfiler. The table existed in dbo._MigrationHistory under system tables.

You try do a few things:

1. You can add CreatedOn (DateTime) column manually to dbo._MigrationHistory table under System tables folder.
2. You can stop detecting changes by setting Configuration.AutoDetectChangesEnabled = false;
3. Comment this line MiniProfilerEF.Initialize(), disabling EF profiling.

Here is an example of the seed method to add the CreatedOn column. This column will be deleted each time the context is initialized. The seed method is in the Configuration class of the context.

internal sealed class Configuration : DbMigrationsConfiguration<MyContext>
{
    protected override void Seed(MyContext context)
    {
        //  This method will be called after migrating to the latest version.

        // Hide error Invalid column name 'CreatedOn' from mini profiler.
        context.Database.ExecuteSqlCommand(
            @"IF NOT EXISTS(SELECT * FROM sys.columns WHERE object_id = OBJECT_ID('__MigrationHistory') AND name = 'CreatedOn')
                ALTER TABLE dbo.__MigrationHistory ADD CreatedOn datetime NOT NULL CONSTRAINT DF___MigrationHistory_CreatedOn DEFAULT (SYSUTCDATETIME());
        ");
    }
}

Diffraction

AutoDetectChanges = false does actually not solve the problem, it also occurs with "manual" migrations.But you are, of course, correct with the other two solutions. Thanks. – Eveland

hmmm i thought i tested it correctly :p thank you for the information – Diffraction

Adding a CreatedOn field doesn't work either, because the next migration will drop it instantly and it'll start all over again. – Atavism

Maybe you could add an Alter table to your seed method. – Diffraction

Answer 4

According to Filip Cornelissen answer following script fixes this problem

--IF OBJECT_ID('dbo.__MigrationHistory') IS NOT NULL

ALTER TABLE dbo.__MigrationHistory ADD CreatedOn DateTime Default GETDATE()
GO
UPDATE dbo.__MigrationHistory SET CreatedOn = GETDATE()

Jungle

Yes it does, but it's only temporary. The CreatedOn column will be dropped again! Just a matter of time. – Atavism

Answer 5

Here's a workaround I'm using. Personally, I'm OK with pressing the green arrow twice (Start debugging and then Continue), but if you really want it to stop breaking, try this Post Build Event which will remove the MiniProfiler PDB:

del "$(TargetDir)MiniProfiler.pdb" /q /s

UPDATE: if that's too much work for you, I created a NuGet package:

PM> Install-Package MiniProfilerContrib.EFMigrationsFix

Pazia