Our team works on a website with ASP MVC5 & EF5. there are 3 machines involved in my question:
Developer's machine
Test server
Production server
So a regular work cycle is: the developer adding features & puts them on the test server when there are some approved tested features they goes to the Production server.
When there are no model changes - everything works great.
But, when there are model changes - sometimes the migration gets wrong.
and the DB get so messed up so we need to backit up, clear everything & copy the data from the backup.
what we do is:
Add migration on dev-env.
Copy all the source to the test/production (Model & Migration folders).
Update database.
when doing this basic cycle some times the migration failes to update because of table already exists; I guess im doing something wrong in the process.
Another bad thing:
we have copy of the development environment on the Test & Production servers - my guess is that we dont need VS on the server in order to update version (we use the VS to run the EF commands from the package manager.
My question is
Is there any best practice/manual regarding dev->test->production process & how to do it right with code first & no visual studio on the servers?
Related
I have MVC project which uses EF code first and I'm trying to publish to azure from Visual Studio but I'm receiving error: "Web deploy task failed: data loss might occur". I did some refactoring including renaming columns and I'm aware why the error occurs but I would like to force the migration because I'm sure that I handled the data loss:-) Nevertheless I have no idea how to skip data loss check. I've found that on SQL project you have option in properties that you can uncheck the 'block potential data loose' but I cannot find anything like that on my MVC project. I've tried to include my own script for schema update without the checks for data loss but EF complains that there are pending migrations, so I've tried to copy missing entries to _MigrationHistory table from my development db but it turned out that it's not that simple ;-) Because my app is still in development phase I have reinitialized db but It will be worth to know how to handle that kind of situation on "real" production environment:-)
Edit:
After some testing I've discovered that when publishing to azure there is now option "update database" which by default generates db update script based on diff on the local and azure db. It differs from the old "Run Code First migration" because the the old one was changing Db initializer to MigrateDatabaseToLatestVersion and on application start the db was migrated & seed was run when there were not applied migrations. The "update database" process in other hand is handled only by generated script and the migrations files and MigrationsHistory table is not used on production, neither the seed method. I was confused on the beginning but now it seems logical that update script gives more control over the database change, you always can modify the script, and furthermore the publish process of moving new code to azure performs only after successful db update.
These is an option called AutomaticMigrationDataLossAllowed, set this to true. And run Update-Database -Force. That should do it.
I have an asp.net MVC website making extensive use of ef and migrations.
i have tried deploying it to a system running windows 10 on a local network but seems like ms has removed that options from the latest release and now deployment using web deploy is only possible on server os's.
No trying to do the same using FTP.
whats the ay to deploy using ftp on a local server. I have already setup FTP publishing but cant seem to figure out how to deploy the db and configure the app to run code first migration after every deploy.
The accepted answer in this forum post helped me out with this exact issue. I added the code given there to Application_Start in my Global.asax.cs
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyObjectContext, MyObjextContextMigration>());
MyObjectContext contexttest= new MyObjectContext();
contexttest.Database.Initialize(true);
Just be aware that this will run your seed method every time you visit your site (at least it did for me). In my configuration.cs I put in a check to see if data existed in my tables, if that data was null then it was ok to seed that table, etc.
How to re-create the database using EF6?
I have tried both of following post but, i don't know why its not working and getting same error.
How do I generate an EF6 database with migrations enabled, without using update-database?
Migrations is enabled for context ''but the database does not exist or contains no mapped tables
I have already published my sample on the web server. I am using Sql Server 2012 Express DBMS.
When i have created my application and published it on web server it was working fine. It has created database automatically. After that i have made some changes in ApplicationDBContext and added some properties in IdentityModes(ApplicationUser). Then I have migrated database on my Local IIS Express and it was working fine. Then I have tried to publish my sample again on web server but, this time it shows an error.
Migrations is enabled for context 'ApplicationDbContext' but the database does
not exist or contains no mapped tables. Use Migrations to create the database
and its tables, for example by running the 'Update-Database' command from the
Package Manager Console.
I have deleted the database on web server and tried again. but, still i am facing same error. Now, there is an empty database without table.
Application is creating database on User Registration.
I have also read this post and tried to call dbContext.Database.Initialize(true); and ((IObjectContextAdapter)myContext).ObjectContext.CreateDatabase() method but, still its not working.
First, automatic migrations are nice for development but it's a hugely bad idea to rely on them in production. Second, at some point you turned off automatic migrations, which is why your production database is no longer having tables created in it.
Go ahead and leave automatic migrations off; even in development it's better to know exactly what changes you're making to your database by generating a migration, seeing the code that will be executed, and only then running Update-Database to apply those changes.
You have a number of choices in terms of getting schema updates into production, but they all boil down to roughly the same procedure.
Generate a new migration against your local database.
If you want to update your production database via SQL, run Update-Database -Script. This will generate a SQL file with the code to run on the database to migrate the schema. Hand this off to your DBA if you have one or review the SQL code yourself and then apply it manually to your database via Management Studio.
Run Update-Database. This time without -Script to make the changes to your local database schema.
If you didn't generate the SQL file in step 2, view your local database in SQL Server Object Explorer in Visual Studio. Right-click on the local database there and choose, "Schema Compare...". Follow the wizard to compare with your production database. In the end, you can either generate a SQL file with the necessary changes that need to be made (which again, you'd hand off to your DBA if you have one), or you can migrate to production directly from Visual Studio. However, this is not really recommended. It's always best to generate the SQL, which you or your DBA can then inspect before applying the changes live.
Chris Pratt is correct BTW.
I had downloaded a project in which I needed to just run "Update-Database
Here are the quick screenshots
Then at the bottom of Visual Studio
PM> Update-Database
DONE
We're considering using EF 4.3.1 code-based migrations, but aren't clear about how to integrate Migrations with our present dev/deployment methodology...
The app in-question is a desktop WPF app, with each desktop having its own SQL Server instance (each with 4 separate databases). It is deployed into a "field" environment with zero local IT support. Any database migration must be done using SQL scripts executed by the installer (probably InstallShield). There will not be anyone available who can run a command at a PMC prompt to upgrade the db when it is deployed/upgraded at a field location. Thus the ultimate "output" from EF Migrations must be a set of SQL scripts, which the installer will selectively apply.
Also, we have multiple developers making concurrent database changes.. there is NO DBA. Each developer simply checks-in their code (model) changes to TFS, and the next time they do get-latest, the changes to the model automatically cause a new database to be created on their dev system. So how can we now have each developer perform their own local migrations (rather than deleting/recreating their local databases), and then manage/consolidate/combine those migrations? And what about collisions?
During dev and unit-testing, each developer may delete their (entire) local database multiple times during a single checkout/checkin iteration. This works great with Code First, since the database gets automatically rebuilt when the app is restarted. But this means that the _MigrationHistory table in the database also gets deleted. How do we handle this? Don't we need the migration history of each dev system? If not, then where/how do we detect the aggregate changes which need to be applied to the delivered system?
I can see the value of using Migrations to deal with the mechanics of migrating a database, but what's not clear is how to take advantage of it without introducing a centralized database "change-control" bottleneck into the dev cycle, and thus losing one of the key benefits of Code First.
Any insight/advice would be greatly appreciated!
DadCat
I know this is an old question but I thought I'd post some of my experiences with EF Migrations (v6.1).
Each dev will be fine. Migrations are put into classes with a timestamp in the name, so no collisions will happen. The DB on the dev's machine will be updated after doing a get latest and running the app (or the update-database command).
Deleting the local db and recreating is fine. Just make sure the dev runs update-database before adding additional migrations or things will get out of sync. I'm a bit confused as to why they'd need to delete the local DB, but that's out of scope. You may find that your process needs to change to accommodate EF Migrations.
I can't help you with the installer question, as a similar question brought me here. The update-database command does have a -script option that will generate the proper change script, but I'm unclear how to automate that on a build server.
The situation at the moment is that we have a sharepoint server which started out as a pilot but now actually runs as the production environment. The server on which sharepoint runs is an old machine which does not conforms the standard requirements so I want to move the current environment to the shiny new server.
I've red a lot about migrating the MOSS services, databases and content and stuff but to be honest I am kinda lost in a sea of information and I can't find the right method to do this, I've tried to install MOSS 2007 on the new server as a clean install, restored the databasses on the new server, restored the backup on the new server which I made with Sharepoint Central Administration, alas, I did not worked :-(
Lots of "Can't find this" and "Can't find that" errors...
It should be possible to grab all the data/sites/subsites/databasses/content/documents and everything else and restore that to the new server right?
Anyways, I was hoping for some step-by-step information... :-)
Regards
Erik404
I think I found a way to do a complete migration...
Install a fresh version of MOSS 2007 on the new server (Server_B). Install the features and solutions you have on Server_A. Then use the SPContentDeploymentWizard which can be downloaded for free from CodePlex to make an export of all site content and import these on Server_B. Also backup custom databases needed by features and create these on Server_B.
I do have a almost completly equal server running now, some funky errors pop up now and then so I don't think it's the best way to do it...
Also, custom developed webparts need to be deployed manually to the new server, I didn't find a way to migrate these
You are on the right track. The CodePlex solution is just a wizard GUI of what you would have to do at the command line via stsadm.
Essentially you:
Build the new server w/ all the patches, Service Packs etc that are on the old.
You will want to run a command at the cmd line to scan for and resolve any orphaned sites in your databases on Server A (command slips my mind but you can find it in TechNet - I think it's repair database - something like that)
Limit access to Server A - so you don't have user changes during your migration.
Prepare the databases for migration - another stsadm command - stsadm -o preparetomove
Detach the databases from Server A. Horrible command of -o deletedatabase - it deletes the reference but not the actual database (but still!)
Attach the databases to Server B
You should be good at that point.
As you've discovered - you can't migrate custom code, webparts etc. These need to be reinstalled. One of the reasons that solutions / features are really recommend for customizations.
Also - the search dbs, indexes etc. need to be recreated. You can't bring those over. But that's fairly straightforward - and makes sense when you think about it.
Use these scripts if you need.
http://globaldeploymentmoss2007.blogspot.ca/