When I create my context using a connection string name, that connection is used as expected, but not by the code running Migrations!
That code creates a new context with the parameter-less constructor which then obviously uses its default connection resolving mechanism and thus connects to a different database!! This seems very undesirable default behavior to me. Why does Migrations not use the current context, or at least the same connection string as the current context?
Am I missing something or is this a flaw in Code First Migrations? And what is the best way to work around this? Implementing IDbContextFactory? Or do somting with Database.SetInitializer in the context constructor?
I actually ended up querying my database without any exceptions occurring (since I did not run any code relying on the migration), and at the same time secretively creating a completely new database in SQLEXPRESS.
Version used is Entity Framework 6 with .NET 4
To prove my findings I added some screenprints from the debugger. The first one shows that the connection taken from connection-string SiteSqlServer is actually used. The second one shows that the connection used in the database initialization code is different. The third shows the stacktrace at the time of the screenprints.
(Hopfully the prints are readable, zooming in helps)
