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: Entity Framework actually doesn't interact directly with the config file, we use [ConfigurationManager](http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.aspx). Most other .NET components do that same thing so that you get consistent behavior. Configuration manager only loads the config file from your startup project (so that you can have multiple startup projects with different config). Whilst we could do something special for migrations (and other tooling in VS) this would probably cause more confusion because migrations would work but then when you run your application it would load different config and try and connect to a different database. We also don't want to deviate from the standard behavior of other .NET technologies. While we agree that it can certainly be confusing, using the config file from your startup application is a fundamental assumption built into .NET and Visual Studio. Coming in EF6 we have a [Code Based Configuration](http://msdn.microsoft.com/en-us/data/jj680699) feature which alleviates some of the issues with config files because you can define your config alongside your context in a class library.
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: Entity Framework actually doesn't interact directly with the config file, we use [ConfigurationManager](http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.aspx). Most other .NET components do that same thing so that you get consistent behavior. Configuration manager only loads the config file from your startup project (so that you can have multiple startup projects with different config). Whilst we could do something special for migrations (and other tooling in VS) this would probably cause more confusion because migrations would work but then when you run your application it would load different config and try and connect to a different database. We also don't want to deviate from the standard behavior of other .NET technologies. While we agree that it can certainly be confusing, using the config file from your startup application is a fundamental assumption built into .NET and Visual Studio. Coming in EF6 we have a [Code Based Configuration](http://msdn.microsoft.com/en-us/data/jj680699) feature which alleviates some of the issues with config files because you can define your config alongside your context in a class library.