Recently I made the switch from using Visual Studio 2015 to using Visual Studio 2017. For the most part the transition was easy. However, I ran into an issue with Entity Framework updating the wrong database. I’m posting the solution here so I don’t forget 🙂
TL:DR
If you are experiencing issues with Entity Framework then check that your startup project is the correct one.
EF Update-Database Is Not Working
My current setup involves using a local SQL Server Express database. I check the database via SQL Server Management Studio (ManStu) when I run Update-Database to ensure my changes take place. When I run Update-Database from Visual Studio 2015 the changes are reflected in the database. When I run Update-Database from Visual Studio 2017 the changes are not reflected in the database.
Why does Update-Database work correctly in Visual Studio 2015 but not correctly in Visual Studio 2017? Why does Visual Studio 2017 tell me that the changes were applied successfully?
I decided to take a look at the output of Update-Database -Verbose to see if it yielded any helpful information. There I saw:
Target database is: 'MySpecialDB' (DataSource: (localdb)\v11.0, Provider: System.Data.SqlClient, Origin: Convention).
Entity Framework was using (localdb)Â and not the SQL Server Express database I setup in the app.config. That explains why the changes were applied successfully. However, why was Entity Framework using the wrong database?
The Not So Thrilling Simple Solution
I pursued a number of different routes looking for the solution to this issue. In the end the solution is so simple. The wrong startup project was selected. That’s it. In Visual Studio 2015 I was using a different startup project. In Visual Studio 2017 I never setup a startup project and so one was selected automatically.
As it turns out Entity Framework pulls meaningful information (like database connection information) out of the startup project. The fact that I had the wrong startup project selected in Visual Studio 2017 was the reason why my Entity Framework Update-Database commands were not working the way I expected.
So, lesson learned, if you are experiencing issues with Entity Framework then check your startup project. It could be that you have the wrong startup project selected 🙂
Which I believe is a user setting, typically excluded from source control.
What was the EF team thinking?
Hi there. I wanted to give you a bit more insight into this. Yes EF4.1- EF6 migrations will look in startup config for the connection string. If it can’t be found then it will follow its convention for inferring. When you add entityframework (ef4.1-4.6) to a project , the package will also create an app.config with some EF configuration in that project with the presumption that this may be your startup project. And that EF configuration sets up localdb as your default database. But there’s no connection string. Therefore, in this situation, ef will use it’s convention (look for a database with the same name as your dbcontext) and because of the configuration it will do so in sql server localdb.
So …most often, you probably want to just get rid of the app.config in your separate data project.
Often I’ll have a UI project with one database defined and if I have a test project, that has it’s own app.config and specifies a different database ..one I can dump and rebuild (losing data etc) as needed for any tests where I want to use a database.
HTH
Thanks. This just helped me solve the issue I was having where migrations were running on the wrong table in my database. Somehow my startup project in VS2017 got set to my unit test project for the Solution. Setting the project with the web.config as the startup got my migrations going to the correct tables again.
Totally saved my ass with this one. I didn’t recently switch versions, but I did set a console application as the startup project in the solution.
I was struggeling with the same problem, two hours further, finally found your link.
Thanks!
You can specify the -StartUpProjectName parameter for both Add-Migration and Update-Database to ensure the connection string you intent to use are actually used.
If you use it alongside -ProjectName to indicate the project containing the migrations, you need not bother about start-up projects and default projects settings.