问题
After upgrading to Entity Framework 6 we've implemented our own DbExecutionStrategy. In addition to existing SqlAzureExecutionStrategy our strategy also logs exceptions.
As turned out, every 15-30 minutes Entity Framework throws internal SqlException
System.Data.SqlClient.SqlException (0x80131904): Invalid column name 'CreatedOn'.
It's an internal error. Seems like EF does some regular checks if CreatedOn column exists on some table. Is there any elegant way to prevent this exception to be thrown?
Here is a call stack:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, ref Boolean dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, ref Task task, Boolean asyncWrite, SqlDataReader ds)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, ref Task task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch(Func`1 operation, TInterceptionContext interceptionContext, Action`1 executing, Action`1 executed)
at System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.Reader(DbCommand command, DbCommandInterceptionContext interceptionContext)
at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
回答1:
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...
回答2:
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.
来源：https://stackoverflow.com/questions/19646659/createdon-column-in-entity-framework-6