J'ai un projet MVC qui utilise d'abord le code EF et j'essaye de publier vers Azur à partir de Visual Studio mais je reçois une erreur: "Échec de la tâche de déploiement Web: perte de données peut survenir ". J'ai fait du refactoring en renommant les colonnes et je sais pourquoi l'erreur se produit mais je voudrais forcer la migration car je suis sûr que j'ai géré la perte de données :-) Néanmoins, je n'ai aucune idée de comment passer la perte de données. J'ai trouvé que sur le projet SQL vous avez l'option dans les propriétés que vous pouvez décocher le 'bloquer les données potentielles lâches' mais je ne trouve rien de tel sur mon projet MVC. J'ai essayé d'inclure mon propre script pour la mise à jour du schéma sans vérifier les pertes de données mais EF se plaint qu'il y a des migrations en attente, donc j'ai essayé de copier les entrées manquantes dans la table _MigrationHistory de mon développement db mais il s'est avéré que si simple ;-) Parce que mon application est encore en phase de développement j'ai réinitialisé db mais il vaudra la peine de savoir comment gérer ce genre de situation sur "vrai" environnement de production :-)Échec de la tâche de déploiement Web: perte de données lors du déploiement sur azure
Editer: Après quelques tests J'ai découvert que lors de la publication sur azur il y a maintenant l'option "mise à jour de la base de données" qui génère par défaut le script de mise à jour db basé sur diff sur le db local et azur. Il diffère de l'ancienne "Run Code First migration" car l'ancien était en train de changer l'initialiseur Db en MigrateDatabaseToLatestVersion et au démarrage de l'application la base de données a été migrée & La graine a été exécutée lorsqu'il n'y avait pas de migrations appliquées. D'autre part, le processus de "mise à jour de la base de données" n'est géré que par le script généré et les fichiers de migrations et la table MigrationsHistory ne sont pas utilisés en production, ni la méthode seed. J'étais confus au début mais maintenant il semble logique que le script de mise à jour donne plus de contrôle sur la modification de base de données, vous pouvez toujours modifier le script, et en outre le processus de publication du nouveau code vers azure ne fonctionne qu'après la mise à jour.
J'ai essayé le 'AutomaticMigrationDataLossAllowed' mais on m'a compté sur l'initialiseur' MigrateDatabaseToLatestVersion' qui ne prend pas ce drapeau en compte (dans mes tests). Pensez que migrer depuis la console du gestionnaire de paquets avec -Force fera l'affaire. Je n'ai rien à tester maintenant et j'ai déjà changé le scénario de mise à jour en script "update database" (plus d'infos en edit) mais je pense que cette réponse peut être acceptée :-) – eldi