Last post Nov 26, 2014 05:23 AM by Kevin Shen - MSFT
Nov 24, 2014 10:35 AM|MJLHThomassen|LINK
Hey all, I hope this is the right place to post this (the link in one of the articles pointed me to this place).
So, I've followed the steps in this tutorial: http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/migrations-and-deployment-with-the-entity-framework-in-an-asp-net-mvc-application to
apply EF Code First migrations to my database. I have 2 questions regarding this.
Question 1: When publishing an app to my webserver using the "Execute Code First Migrations (runs on app start)." option, is it possible to specify which migration to use?
Why I want this: Our company is currently running a non code-first database which first needs to be "bootstrapped" with an empty migration in order to start supporting EF Code First migrations. I've been able to get this working locally using the NuGet Package
Update-Database -TargetMigration <NameOfMigration>
This works great. I have two migrations, the inital migration, created with
Add-Migration InitialMigration -IgnoreChanges
and a migration which actually pushes some changes i made to my datamodel vs the data which is in the database right now (lets call this MigrationA).
Now from my console, I can, run
Update-Database -TargetMigration InitialMigration
this first does the empty "bootstrap" migration to prep the database for EF Code First migrations and then the actual MigrationA. Now i want to do the same trick on my production machine. Is this at all possible?
Question 2: Is it possible, during the Seed method which is called after a migration runs, to give some sort of feedback? I know this runs the first time the application is accessed from the outside so it might be a bit problematic (i actually assumed the
migration ran as soon as I published in Visual Studio, but this is not the case). The reason i want to have some feedback is because the MigrationA mentioned above contains some changes which require me to generate a bunch of new data for my storage which
is references from my database. This can take up to 2 hours because it really is a lot of data in a lot of small files which just takes long on our production machine. I dont want to sit in the dark for 2 hours waiting for my application to load, praying nothing
went wrong. So yeah, is there some kind of Console.WriteLine equivalent to use in the Seed method to give me some feedback about the seeding process?
Nov 26, 2014 02:06 AM|Kevin Shen - MSFT|LINK
For your first issue, you can do the same trick on your production machine. But only when you change your connection string to the production machine.
For your second issue, as far as I know ,there seems no way of Console.WriteLine equivalent to use in the seed,I suggest that you can add try /catch block in your seed method to check if the seed method went very well.
Nov 26, 2014 04:26 AM|MJLHThomassen|LINK
Thank you for your answer.
As for changing the connection string to our production machine, that is currently not possible. Our production machine is being hosted by another company which has very strict firewall and port forwarding settings. Currently we only have port 80 (for the
web application we are running) and the RDP port open. The web app connects to our SQL server locally since both are running on the same machine, so no port forwarding is nessecary there. But if i want to access the SQL server from outside, the firewall and
port settings are blocking it. An option is to copy a small program which does the migration to the server and run it, but i dont want to do that everytime i publish a new version which has database changes. Thats why i wanted to use the nice EF Code First
migration option while publishing in the first place ;)
As for my second issue, i could indeed try to have a try/catch. I think that is a smart idea anyway, and have it write to a log file if things went well. I think there is not much of an other option in that area available. Thanks for the tip.
Nov 26, 2014 05:23 AM|Kevin Shen - MSFT|LINK
Since your application can not access the production machine, So you have to copy a small program which does the migration to the server.
I agree with you the idea that you can add try catch block and log the exception.