After upgrading to Entity Framework 6 we\'ve implemented our own DbExecutionStrategy. In addition to existing SqlAzureExecutionStrategy our strategy also l
In a past Entity Framework used to have a column "CreatenOn" in __MigrationHistory table.
Every time the AppDomain starts it checks if Migration is required the the database. EF actually tries to read "CreatedOn" columns and obviously fails with the exception which gets logged. EF has an ugly try/catch all block around this check and if the exception is thrown (column is missing) then it doesn't try to "migrate" CreatedOn column.
There is no way at the moment to disable that check, except just not to log it...
In my case, this error was happening because I had changed Visual Studio Debug Exceptions settings to break in all exceptions (or in more exceptions than the default configuration). After resetting all settings of Visual Studio, the error didn't happen anymore, and my application ran normally as expected.
The problem then is that Entity Framework has a try/catch block to handle this error so that the application doesn't stop working when this error happens. After handling the error, it returns the application to a normal state, as you might do also in your own application's try/catch blocks. Thus breaking on these exceptions was making my code stop unnecessarily.
Breaking in all exceptions was necessary while I was debugging a complex program, but I should have had reset the debugging exceptions settings after I didn't need it anymore. Hope this may help someone else going through this same hard to catch environment issue.