Project works localy, but on release return startup error. Application startup exception:
stdout returns
Application startup exception: System.Data.Entity.Migrations.Infrastructure.AutomaticDataLossException: Automatic migration was not applied because it would result in data loss. Set AutomaticMigrationDataLossAllowed to 'true' on your DbMigrationsConfiguration to allow application of automatic migrations even if they might cause data loss. Alternately, use Update-Database with the '-Force' option, or scaffold an explicit migration. at System.Data.Entity.Migrations.DbMigrator.AutoMigrate(String migrationId, VersionedModel sourceModel, VersionedModel targetModel, Boolean downgrading)
i already used Update-Database -Force, successfully but no positive result and error continue(database is fully updated)
Has anyone had this problem or something similar?
CodePudding user response：
Project works locally, but on release return startup error.
This is a common occurrence if your Release configuration does not have the same database connection string. If you were expecting your release build to use the same database, the one that you have been debugging against, then check that you don't have a different config file in the output folder of your release build.
Automatic migration was not applied because it would result in data loss.
This indicates 2 things:
- You are using automatic migrations, not explicit migrations
- A required schema change is either dropping a table, column, foreign key
- Another common data loss scenario is when tables or columns are renamed. This is still the second issue if EF does not detect the change as a rename and instead implements drop and create logic.
(As directed in the exception message) The ideal solution to this is to use explicit migrations, that way you can implement your own customised migration logic for specific versions that might result in data loss. You may only need one explicit migration for this particular schema version.
After refactoring operations that involve multiple changes, potential rename actions might be ambiguous or not detected at all. In your explicit migration you can replace drop and re-create logic with rename operations, you can also change the order of drop and add/create to allow you to add the new column or table, then add an SQL statement to migrate the data from the old implementation to the new one, then execute the drop statements after mitigating the data loss.
using the -Force option won't always work. It will allow you to bypass the warnings, but it won't help SQL to execute that will violate database schema constraints. To further debug if -Force doesn't work, capture the verbose output to analyse the last SQL statement that causes the process to fail:
Update-Database -Force -Verbose
Other workarounds:
- Drop the production database manually, this will result in the schema being recreated to match your EF data model. This of course will result in total loss of data, so it is only applicable to essentially first time or OOTB application deployments.
- Manually remove the offending schema elements