At the start-up of our application we call EF code first's Database.Initialize(force=true) method to initialize the local database. On some computers when the user attempts to start up the application right after logging in to the user account the Migrations are triggered and the application crashes because the first Migration tries to add tables to the database that are already there. The second (or third) time the user launches the application no Migrations are triggered and the application starts up succesfully.
So to summarize:
The application starts.
It calls Database.Initialize(true);
EF does not see the database and triggers the Migrations to create it.
The first Migration tries to add tables to the database and crashses because the database was there after all.
This behaviour is only seen after a launch of the application shortly after logging in.
Does anyone have any inkling to about what is going on?
EDIT Extra info:
- We use EF 6.1.3
- We assign the initializer thus:
Database.SetInitializer(New DbInitializer),DbInitializerinheritingMigrateDatabaseToLatestVersion(Of OurDbContext, Migrations.Configuration)
I notice now that the DbInitializer is assigned in the static constructor of OurDbContext , but that the Database.Initialize method is invoked from another class. This may very well be the root of the problem.
The problem seems indeed to be related to the fact the assignment of the
MigrateDatabaseToLatestVersionimplementation was called in the static constructor of the DbContext while theDatabase.Initializecall comes from an other class. On some systems it seems then that the initializer is changed from DropCreate to Migrate halfway during initialization, or that the connection string changes.