I just spent a day figuring out an issue ([as per this stack question](http://stackoverflow.com/questions/15553199/ef-5-migrations-cannot-connect-to-our-database-even-though-it-does-just-fine-at)) and now I feel rather dumb.
It turns out that even though I had the right project selected to run migration commands against...
...migrations uses the startup project to find the connection string. I apparently had a silly class library selected as the startup project and EF was not very happy about that.
I know that once upon a time EF would use the app.config file in the project where the data context was located. I remember that being really confusing when I was first learning because at runtime it used web.config for obvious reasons. So using the startup project is a great fix for that situation.
I suggest that EF migrations look in the startup project for a config file, but if it does not find one or the config file does not have a connection string with the name of the data context then it should also look in the project where the data context is located.
This fallback would make things much easier and far less confusing. That way the user who puts his connection string only in web.config will still be fine, and others like me who expect it to use app.config will also be fine :)
Comments: Whilst we agree this is confusing at times, it would be even more confusing to have parts of EF (or even all of EF) deviate from the standard config loading behavior. See previous comment for more details.
It turns out that even though I had the right project selected to run migration commands against...
...migrations uses the startup project to find the connection string. I apparently had a silly class library selected as the startup project and EF was not very happy about that.
I know that once upon a time EF would use the app.config file in the project where the data context was located. I remember that being really confusing when I was first learning because at runtime it used web.config for obvious reasons. So using the startup project is a great fix for that situation.
I suggest that EF migrations look in the startup project for a config file, but if it does not find one or the config file does not have a connection string with the name of the data context then it should also look in the project where the data context is located.
This fallback would make things much easier and far less confusing. That way the user who puts his connection string only in web.config will still be fine, and others like me who expect it to use app.config will also be fine :)
Comments: Whilst we agree this is confusing at times, it would be even more confusing to have parts of EF (or even all of EF) deviate from the standard config loading behavior. See previous comment for more details.