Is code first migration automatically run on the server? - c#

I am very familiar with Entity Framework using Database First approach and how to deploy the solution with it.
Basically, in my solution with database first approach, I have a web client project that consumes data access library project that is coded with database first approach.
So, first, I write some SQL Server scripts to add new tables (or make schema changes).
Next, go to the data access library project, using EF edmx designer to update .net from existing database, compile this data access layer, and the DDL reference is automatically updated in the client web project.
When I deploy the solution to the production server:
First, I need to run the t-SQL scripts on the production SQL server
Next, I deploy the 2 updated DDLs (one for the web and 1 for the data access layer) on the web server.
Now, I have a new application that includes a web project and a data access layer project that uses EF Code First approach.
I am new to EF code first approach. I know any time when I change the database schema, for instance adding a new table, I need to run code first migration in the Package Management Console in Visual Studio to let my back-end database instance change/update.
My question:
When I deploy the application to the production, what are the steps I should follow?
How is the production SQL server updated that is created with EF Code First approach?
Is it a automatic process or I have to run the migration manually like I do inside Visual Studio under the Package Management Console?
Thanks.

If you're using Azure then you can configure it has automatic process as shown below.
Else you have to do it manually like this :
You have to create a db script and after that you can run it on your production db.
PM> Update-Database -Script
You can refer this doc : Getting a SQL Script
Another option where I normaley use :
When I need to run migrations aginst the production db,I change my conn string to reflect production db and after that run :
PM> Update-Database

You have several options with migrations.
You can generate a script using Update-Database -Script (as #Sampath notes)
You can run Update-Database -ConnectionString="YourDbString" and it will do it against the production database for you
You can use a migration initializer and on app startup it will use the applications connection string to run the migration. Do this by putting a line similar to this in your initialization routine:
Database.SetInitializer(new MigrateDatabaseToLatestVersion<Context, Configuration>());
Where Context is your DbContext type and Configuration is the configuration class generated when you made the first migration.
See this MSDN article for more information: https://msdn.microsoft.com/en-us/data/jj591621.aspx

Related

How to safely drop Compact SQL database migration history

I'm developing a WPF app utilizing a SQL Server Compact 4.0 database. For the course of this project, we made several changes in the model structure with a number of code-based and later with automatic migrations. They all are stored in the _MigrationHistory table and represented by several migration classes.
Now it appeared that I need to considerably change the model. Since the app is still in the development phase, dropping data in the database is not a concern. I would like to get rid of the whole previous migration history and start a new clean model. So my question is what steps are to remove the whole history of migrations and start a new history with automatic migrations in the future.
What parts of the project must be deleted and how to do it safely?
First Make sure your project is backed up and your database is also backed up. In case something goes wrong.
If your project is setup using entity framework code first,
In the project you can delete all the migration files in the 'Migrations' folder except 'MigrationConfiguration.cs' contained within the project that is using entity framework.
Also if you are not concerned with dropping the database, then go-ahead and delete the entire database, then create a new one with the same name that is configured in your database context connection string found in your project's config file.
Rebuild your solution and create a new migration by typing the command in the package manager console 'add-migration' and provide a name. This will create a new migration to create the database for all your code first models. If the generated migration file looks correct, then run 'update-database' in the package manager to apply the migration to your empty database.

Code first migrations when using Filesystem based publish

I am relatively new to this. I am trying to publish my asp.net web application to a production IIS server. In visual studio I select Filesystem based Publishing, since web deploy is not supported by that server.
I use Code First Migrations for my Databases. As long as it is the first time, or if I drop all my tables, the deployments to production work fine. However if I have existing tables with production data, I get the error below -
"The model backing the 'ApplicationDbContext' context has changed since the database was created. Consider using Code First Migrations to update the database"
How do I enable automatic schema updates when my model changes? I have "AutomaticMigrationsEnabled" my Configuration.cs set to true. Do I need to set something in my global.asax or Web.Config? What am I missing?
On my local server I can run Update-Database. How do I make this automatically happen in production whenever I push model updates?
UPDATE:
I was able to get rid of the error in production by following the steps in Using Entity Framework (code first) migrations in production
However I am not sure if this is the best way to fix the problem. Or if I wanted production to keep running this line every time the application starts.
Database.SetInitializer<ApplicationDbContext>(new
MigrateDatabaseToLatestVersion<ApplicationDbContext, Configuration>());
When you use MigrateDatabaseToLatestVersion it will indeed run your migrations for you. So you definitely need that or one of the alternatives like using DbMigrator in code or generating a script (update-database -Script).
These will run the migrations in your folder. The problem is you have AutomaticMigrationsEnabled = true in your configuration. This tells EF to just automatically update your database and does not create the code based migration file.
There are a couple of solutions. First, you could add a manual migration before you deploy (add-migration MyMigrationName) or you could switch your initializer to something like CreateDatabaseIfNotExists and then call the migrations in code as shown above.
See here for a detailed explanation.

How to add missing migrations for Identity? (Invalid object name 'dbo.AspNetRoles')

I have created an asp.net application and on my development machine it created these built in tables which is necessary to use the identity part in asp.net mvc.
However, after the initial create when I had to create an SwitchToIdentityDbContext migration which had all the logic to create these tables. But in my application at the time, these tables did already exist so I removed that logic. After that (I think) it resulted in the missing tables for identity when I try to deploy my application to a new datasource that does not have these tables.
Is there a way to generate the missing migrations in order to get this running?
As of now, I have this in my config:
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
Even if I remove that migration and add a new one, it's empty.
If you don't care for the data residing in your database, one option to correct the schema is to delete all your .cs migrations in Visual Studio and all records in your dbo.__MigrationHistory table in your database. After that you can try to create a brand new migration in Visual Studio to fix the database.
However if that doesn't work, you can clear all your migrations in Visual Studio and completely obliterate the database. Then run
add-migration CreateMyDb, then update-database
and you should be good to go.
If you do care for your data, you can always export the contents of your database tables to .csv files in Server Management Studio (if you use it) before destroying the migrations.

How to change database after altering model in MVC?

I'm new to ASP.NET and I'm working on this project that uses MVC. It's a simple website development project, and it uses SQL Server CE (.sdf) as the database.
I would like to change a couple of the underlying models, but that causes errors in the database.
I understand that I would need to change the database, and I know it's possible to create models automatically from the database.
I'm wondering if there is any way to create a database from the models. i.e. I don't mind losing all the data, but is there a way for me to change the models and then create a database that supports the existing models.
I hope that makes sense
Yes it possible to
Here is how you can do it.
There are two approaches to accomplish this task.
Method-1. (Via Package Manager Console)
This approach for the Code First.
Open your project and go to Package Manager Console as follows
Tools--> Nuget Package Manager--> Package Manager Console
First Enable Migrations in your project.Type following in console.
enable-migrations -contexttypename yourContextName
This command will add a Migrations folder in your project inside this folder you will
see Configuration.cs inside this file you will see a seed method
protected override void Seed(YourContext context)
you can use this method to seed your database.
Now run following command in your package manager console
add-migration anyNameOfInitialMigrations
Finally To update the database simply run following command.
update-database
Method-2.
Best approach for Model First.
Open your .edmx file.
Right Click--> on the model and then select "Generate Database From Model"
Make Sure you have proper connection strings in your web.config.

The model backing the '--Context' context has changed since the database was created - but db is new production database

I've got this error for the 762nd time but this time I am getting it as soon as I attempt to access my Production site, straight after deleting the 'production' database on Azure and then publishing my site.
The model backing the 'PropertyContext' context has changed since the database was created. Consider using Code First Migrations to update the database
I deleted the database because I couldn't fix this issue any other way but it still doesn't work.
Some important points:
I'm using EF6 and publishing to Azure.
This is 1 of 2 projects/sites that uses the same Repo project. I have no
problems with the other one, just this one.
I have tried publishing the problem project first (after deleting the db) and
second with the same result.
I have tried deleting both WEBSITES and the DB from Azure and starting again
I have tried deleting all migrations and starting with a fresh data model
I have tried the following in my Global.asax (in both projects)
Database.SetInitializer PropertyContext>(null); <-- SO won't let me put the first <
and
Database.SetInitializer(new MigrateDatabaseToLatestVersion<PropertyContext, MyConfiguration>());
new PropertyContext().Database.Initialize(true);
I'm using .net 4.5
Why am I getting this error on a new database and how can I get this site to work?
Just ran into the same error in ASP.Net application. In my case I did not use Code First, but I used standard ASP.Net authentication provider which apparently uses Code First, and authentication was broken because of this issue.
Here is quick and dirty solution is you don't care much about existing user records:
For me the solution was to drop the dbo.__MigrationHistory table, authentication started working fine after that. Be aware! This solution is not for everyone! This will fix the problem, but it is potentially risky.
If you cannot afford to lose data in AspNet* tables:
ASP.Net authentication provider automatically creates tables in your database:
AspNetRoles
AspNetUsers
AspNetUserRoles
AspNetUserClaims
AspNetUserLogings
The tables are empty by default, if you haven't created any new logins for your web site, you can use "quick and dirty" solution above. If you do care about preserving user information or just curios how Code First migrations work, follow these steps:
Open your Web.config file and check the name of the connection string you have for your database. It will be one of the records under <connectionStrings> element.
Open Package Manager Console:
Tools –> Library Package Manager –> Package Manager Console
In Package Manager Console window, use a drop-down to set Default Project. Make sure this is the project that contains ASP.Net authentication provider code.
Execute command:
Update-Database -ConnectionStringName MyConnectionStringName
Replace the MyConnectionStringName with the actual name you looked up in web.config.
As a result of this command you will see a new folder "Migrations" with a bunch of code generated by the Update-Database command. Re-build and re-deploy your app, your new migration code will be executed on startup and would bring the database schema in sync with an updated version of ASP.Net authentication provider code.
When using Code First with Migrations, your database creates a table called __MigrationHistory to track the current schema. When you run your application your Entity Framework will check this table to make sure that the database schema matches your database entities. If they do not match, you will get this error.
To update your database follow these steps:
Open the Package Manager Console (View -> Other Windows -> Package Manager Console) in Visual Studio
In the Package Manager Console Window, there is a drop down with your projects in, make sure it is set to the project that contains your DbContext
Make sure that the project that contains your App.Config / Web.Config file is "Set as Startup Project" (If you have multiple Configs, it must be the one with the Database Connection String defined.
Type Update-Database -ConnectionStringName MyConnString where MyConnString is the name (not the actual connection string) of your connection string in your App.Config / Web.Config
If you get an error like this: "Unable to update database to match the current model because there are pending changes and automatic migration is disabled."
You should enable Automatic Migrations and try again.
To enable Automatic Migrations
In the Migrations folder (in the project with your DbContext), open Configuration.cs.
Make sure the Constructor contains: AutomaticMigrationsEnabled = true;
To stop Entity Framework/DbContext from monitoring changes on your database you could simply delete the __MigrationHistory table in your database. It is then up to you to make sure that the database remains updated manually.
MSDN article here
The solution from this is to use the static method SetInitializer and bind to the context a Null value. If you are working on a Web solution, the best position to write the code is in the Application_Start of your Global.asax.cs file.
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RegisterRoutes(RouteTable.Routes);
//...
Database.SetInitializer<MyContext>(null);
}
I got a similar problem this morning. Suddenly the error appeared and couldn't be resolved:
The model backing the 'ApplicationDbContext' context has changed since
the database was created. Consider using Code First Migrations to update
the database
I have one project for MVC and another project for the model, context and repositories. I've been working on it for weeks but today it said stop.
I have tried to delete database, enable-migration, add-migration and update-database so many times that I've lost count. I've added initializers to MigrateDatabaseToLatestVersion as well as DropCreateDatabaseIfModelChanges. All in vain...
What finally made it work was to move model, context and repositories into the MVC project (not something I was keen on)...then it worked right out of the box without any code changes at all (besides namespaces)! Very strange...
I've read so many blog posts during the day trying to solve this problem. One of them (I don't know which one) mentioned a bug in Visual Studio 2013 where reference to DLL files weren't always updated as they should, suggesting that my MVC project missed out something when I was running add-migration and update-database in my separate project. But it's just a guess.
I'm using EF 6.1 and .Net 4.5.1 in my solution.
Got a similar problem! Answer is here
http://www.asp.net/mvc/overview/older-versions/getting-started-with-aspnet-mvc3/cs/adding-a-new-field
(Rick Anderson)
There are two approaches to resolving the error:
Have the Entity Framework automatically drop and re-create the database based on the new model class schema. This approach is very convenient when doing active development on a test database, because it allows you to quickly evolve the model and database schema together. The downside, though, is that you lose existing data in the database — so you don't want to use this approach on a production database!
Explicitly modify the schema of the existing database so that it matches the model classes. The advantage of this approach is that you keep your data. You can make this change either manually or by creating a database change script.
I have spent some hours trying to solve this problem. One project was working, the other one wasn't.
I had different projects referencing different versions of Entity Framework. In my case, I had a Console app and a Windows Service app, both referencing a third project containing code first classes and DbContext.
After running Update-Package EntityFramework everything worked fine in both projects.

Categories

Resources