I'm using Windows Azure to host an ASP.NET MVC4 web application. I want to use database first-programming, and followed this tutorial to create a database and data model.
I then created a website with a linked database in Windows Azure. I downloaded the publish profile and imported it through VS2012 into the project. I noticed that the database connection strings were not included, so I collected it from the database created in Azure.
In the publish wizard under tab "Settings" I was able to to check a box called "Update database" and when I published the website for the first time, everything went perfect and the website and database was uploaded.
Then I did some changes to the database, updated the data model as described in above mentioned tutorial, updated my code and built the project. This time, when I entered the Publish wizard and selected the "Settings" tab, I am no longer able to check the "Update database" checkbox. Instead there is a disabled checkbox called "Execute Code First Migrations (runs on application start)".
Why can I no longer select the "update database" checkbox? Do I have to update the database manually from now? I tried to create the datamodel again, but it did not help.
This is a completely normal behavior. You set that option for the first time and on successive deployments the code-first migrations will take place on application start. EF (Entity framework) will start the Code-First migrations then.
Especially when you update your model manually.
You will not have to update your database manually. It will be done on application start. When your web-app is started, if you select the migration option.
Read more in detail here:
EF Code First Migrations Deployment to an Azure Cloud Service
Related
I have 2 databases, development and production.
I added a new entity, added a migration then updated the development database.
It worked, development database has the new table.
I switched the database in my configuration to the production database.
I used Update-Database command from Package Manager Console but nothing happened.
My production database still doesn't have the new table.
What now?
What is the valid workflow for such scenario?
BTW, both databases already contain structure and data. The production database contains more recent data, the development database is one migration ahead.
UPDATE: I tried to revert the last migration on development database, it worked. Then I tried to apply it again on production. Didn't work. It seems like it refuses to apply the same migration again.
OK, I figured it out.
I assumed when I change the runtime profile for production the file appsettings.Production.json will be loaded on migration.
It didn't happen. The migration used appsettings.Development.json instead.
I changed the connection string in my appsettings.Development.json file to the production database and it worked.
It's weird, when I debug the web application it respects the settings. It either uses the development or production settings, as selected in Visual Studio. Migrations just use the development file.
If there's a cleaner way (IDK, tell the Update-Database command to use a different appsettings file), please let me know in comment.
I'm faced with this scenario: I want to release my software into production on Azure, but there's a code-first database migration that must be applied at the same time to an Azure SQL database. During the time that new software version is pushed without the new database schema (or vice-versa), there will be a period of time that software will throw the exception The model backing the 'BlogContext' context has changed since the database was created..
My software is deployed upon pushing git commits to a branch using continuous integration in Visual Studio Team Services, so I really need a way to run update-database at the same time.
It appears this can be done using a manual publish from Visual Studio by checking the Update Database box (below), but I need this to be automated.
If you do not care about the data just drop the dbo.__MigrationHistory table
Hope this helps.
Can you take direct control over the deployment process (Team Services can help, or Octopus, Jenkins, others)? If so, deploy the database ahead of the code. That's how I would do it if I wasn't using Entity Framework. I would assume the same even with Entity Framework.
An entity framework context is initialised, by default, using CreateDatabaseIfNotExists<TContext>. If the database schema is different than the EF model, then error The model backing the 'BlogContext' context has changed since the database was created. will be triggered.
By adding to your db context contructor Database.SetInitializer<context>(null); the model error will not be triggered. This means you can deploy schema changes to production, without causing model errors, ahead of the new version of the application being deployed that contains the new db context, which equals no down-time.
Make use of an appSetting so that production code will use the null initializer.
I have a team developing a web application using EF. They all have local copies of their DB, as well as there being a central DB for a published version of the app. Some of the devs, and the CI server, have built their initial DB from a later version of the model than others, and so when they run Update-Database or the migrate.exe tool, they get errors when running migrations they don't actually need.
Other than blowing away all DBs and starting over, what's the best way to get everyone on the same page migrations-wise? Can migrate or Update-Database be told to mark migrations as being applied even if they fail, and continue?
I have an Azure website being deployed using the source control deployment and am using EF Code First Migrations to manage my database schemas. Everything is set up and appears to be functioning properly and it deploys without errors, but there are only 4 migrations in my migration table in the database and there should be 5. My application is also throwing the following error when I try to hit the database
The model backing the 'dbContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).
indicating not all of the migrations have been run. Is there somewhere on Azure I can look to see more detailed log files on the deployment and does anyone know why the migrations would run locally but not on azure?
Add this to your db context contructor:
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, Data.Migrations.Configuration>());
note: change "MyContext" to the name of your context.
I guess I should have thought of this before I started my project but I have successfully built and tested a mini application using the code-first approach and I am ready to deploy it to a production web server.
I have moved the folder to my staging server and everything works well. I am just curious if there is a suggested deployment strategy?
If I make a change to the application I don't want to lose all the data if the application is restarted.
Should I just generate the DB scripts from the code-first project and then move it to my server that way?
Any tips and guide links would be useful.
Thanks.
Actually database initializer is only for development. Deploying such code to production is the best way to get some troubles. Code-first currently doesn't have any approach for database evolution so you must manually build change scripts to your database after new version. The easiest approach is using Database tools in VS Studio 2010 Premium and Ultimate. If you will have a database with the old schema and a database with the new schema and VS will prepare change script for you.
Here are the steps I follow.
Comment out any Initialization strategy I'm using.
Generate the database scripts for schema + data for all the tables EXCEPT the EdmMetadata table and run them on the web server. (Of course, if it's a production server, BE CAREFUL about this step. In my case, during development, the data in production and development are identical.)
Commit my solution to subversion which then triggers TeamCity to build, test, and deploy to the web server (of course, you will have your own method for this step, but somehow deploy the website to the web server).
You're all done!
The Initializer and the EdmMetadata tables are needed for development only.