Les migrations EF Data ne détectent pas les modifications lors de l'ajout d'une nouvelle migration
J'utilise les migrations de données Entity Framework 5.0 avec le code en premier . Lorsque j'ajoute un nouveau champ à mon modèle et que j'exécute la commande suivante dans la console du gestionnaire de packages.
"Add-migration AddedField"
Tout ce que je reçois est une migration vide appelée "n_AddedField", les méthodes up et down ne contiennent aucune logique.
J'ai essayé de nombreuses choses: réinstaller le paquet nuget EF, nettoyer ma solution, reconstruire, supprimer manuellement tous les fichiers et répertoires générés.
Ensuite, j'ai décidé de supprimer toutes mes migrations et de recommencer, puis tout cela est devenu étrange… .. Après avoir supprimé toutes mes migrations et la table historyhistorique de la base de données, j'ai recréé la base de données à l'aide de l'initialiseur CreateDatabaseIfNotExists. Cela fait, je devrais pouvoir créer une nouvelle migration initiale. Mais lorsque j'essaie de créer une nouvelle migration, j'obtiens une erreur indiquant qu'il y a des migrations en attente et répertorie toutes les migrations que je viens de supprimer de mon projet.
Je ne sais pas du tout pourquoi et comment EF se souvient encore de ces migrations ..__ J'ai même essayé de chercher dans les contenus de fichiers pour savoir si les migrations avaient été enregistrées ailleurs ou dans un autre but. Mais rien..
Les migrations de données ont vraiment l'air super quand Scott Hansleman en fait la démonstration, mais pour un vrai travail, je commence à chercher des alternatives.
Lorsque le projet a démarré, nous utilisions EF 4.x et il y a quelques temps, nous sommes passés à la version 5.0, mais depuis le commutateur, j'ai ajouté de nombreuses migrations.
Quelqu'un a-t-il une idée de la façon de résoudre ce problème? Je veux simplement pouvoir ajouter des migrations et générer un script SQL avec les modifications.
J'avais un problème similaire lorsqu'une nouvelle migration n'était pas trouvée. update-database m'indiquait l'erreur suivante, peu importe ce que je faisais:
Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.
You can use the Add-Migration command to write the pending model changes to a code-based migration.
Faire un "nettoyage par lots" a résolu mon problème, suggérant qu'EF utilisait un ancien/invalide Assembly provenant d'un dossier autre que la "configuration de solution actuellement sélectionnée (par exemple, DEBUG)".
Pour nettoyer un lot:
- Sélectionnez
Main Menu -> Build -> Batch Build... - Cliquez sur
Select All - Cliquez sur
Clean
Fermez la boîte de dialogue, reconstruisez et réessayez la migration.
J'espère que cela aide quelqu'un d'autre là-bas.
oops. Dans mon cas, j'ajoutais une nouvelle entité racine non référencée par aucune autre entité. Le résultat était simplement que le code n'avait d'abord aucune raison de générer une migration pour l'entité. Une fois que j'ai ajouté le code dans le DbContext (un dbset) cela a fonctionné comme un charme.
Je viens d'avoir le même problème, mais j'ai compris que mon nouveau champ avait été ajouté en tant que variable membre et non en tant que propriété. Il manquait le {get; set;} part, ce qui fait que la migration ignore ce champ.
Ce n'est peut-être pas votre cas, mais cela pourrait aider quelqu'un d'autre.
Vous êtes «désynchronisé» - base de données, migrations, code - et vous pouvez vous attendre à toutes sortes de problèmes de ce genre.
J'ai fait ce million times (presque :) et cela fonctionne vraiment bien - mais vous devez rester stable et méticuleux dans ce que vous faites.
Vous pouvez lire ce «résumé» que j'ai fait - commencer à mi-chemin quelque part (mais aussi vérifier la connexion).
... et si cela ne fonctionne pas, je vous conseillerais de créer un petit scénario/modèle "reproductible" - publiez exactement ce que vous avez.
Comment fonctionnent les migrations:
Les migrations sont liées à la "table de migration".
Lorsque Add-Migration est exécuté - il vérifie par rapport à la structure et à la table de migration de la "base de données existante" et fait la "différence" (parfois, vous n'obtenez pas de "haut" "simplement" car ils sont également synchronisés).
Ainsi, chaque "migration" est un diff complexe entre votre code, vos migrations existantes, votre base de données et votre table de migration. À part la suppression de la base de données, rien d'autre n'est certain de réinitialiser - la table de 'migration' de Db n'est peut-être pas suffisante - cela ne garantit pas un «nettoyage» complet (si possible, je supprime toujours complètement la suppression de Db). Vous devez également supprimer vos migrations de code.
Assurez-vous de "compiler" les projets (il est préférable de les faire compiler automatiquement dans la configuration) après/avant si nécessaire.
Assurez-vous que votre «connexion» correspond.
Une fois que tout est synchronisé - tout devrait fonctionner correctement - mais vous devez le garder synchronisé. Sauf si vous envisagez de supprimer la base de données (test), ne supprimez pas les migrations de cette manière (vous pouvez utiliser Update-Database -0 (je pense) pour revenir à une migration (il s'agit de "l'état zéro").
J'ai eu un problème similaire à celui-ci: utiliser l'indicateur -force sur add-migration pour rééchafauder une migration existante a cessé de fonctionner sans raison apparente.
Peu importe ce que j'ai fait, j'ai reçu le stupide message d'erreur "Impossible de générer une migration explicite car les migrations explicites suivantes sont en attente". Après avoir essayé à peu près tout ce que je pouvais penser et m'être arrêté juste en écrasant mon ordinateur portable, par désespoir de cause, j'ai de nouveau exécuté enable-migrations et bien sûr reçu le message "Les migrations ont déjà été activées dans le projet 'Blah.Blah'". Essayé add-migration -force encore et comme par magie cela fonctionnait.
Je n'ai aucune idée de ce que cela a changé - il doit s'agir de certains paramètres utilisateur/fichier de configuration en dehors du contrôle de source. J'espère que cela aidera quelqu'un d'autre.
L'option de construction par lots -> nettoyer n'a pas fonctionné pour moi.
J'ai résolu le problème en:
- Création d'une migration avec 'Add-Migration NameOfMigration'
- Suppression du contenu des fonctions de montée et de descente de la classe de migration créée.
- Mise à jour de la base de données en exécutant le script de migration (qui ajoutera une ligne à la table _MigrationHistory avec 'Update-Database -Verbose'
L’application Web fonctionnant maintenant avec succès, j’ai eu un problème qui a été résolu en ajoutant des métadonnées uniquement.
Le problème dans mon cas a été causé par:
- Créer une migration (avec succès)
- Décidez que je veux le recréer et supprimez le fichier de migration
.cs - Essayez de le régénérer et obtenez les fonctions
DownetUpde la migration vide.
Dans ce cas, j'ai oublié de supprimer également les entrées ApplicationDbContextModelSnapshot.cs pour les modifications de modèle. Supprimer les nouveaux mappages de ce fichier a résolu mon problème et il a ensuite été généré correctement.
J'ai ajouté une nouvelle classe à mon modèle de données dans un sous-répertoire. L'espace de noms résultant n'était pas visible pour l'échafaudage à l'aide de add-migration.
Fix était de renommer l’espace de noms de la nouvelle classe pour qu’elle soit conforme au reste du modèle, et/ou d’ajouter «public virtuel DbSet ..», etc. à votre classe de contexte d’entité, ce qui vous obligerait à référencer ce nouvel migration à nouveau.
N'oubliez pas d'inclure le modificateur d'accès Public:
public string Text { get; set; }
J'ai dû supprimer la table _MigrationHistory générée par EF. Ensuite, j'ai relancé add-migration. Soyez prudent avec cela car il va générer les requêtes nécessaires à partir de zéro, y compris les tables qui sont déjà là.
Il semble que j’ai réussi à résoudre le problème en déplaçant les modèles et la classe de contexte vers un autre projet.
Je ne sais toujours pas pourquoi c'est arrivé, et cette solution n'est vraiment pas du tout une solution :(
Peut-être le plus stupide de tous:
J'ajoutais une migration avec le même nom comme nouvel objet que je créais.
J'ai eu le même problème. Les migrations étaient activées mais elles ne détectaient aucun changement. Ma solution consistait à réactiver les migrations en utilisant l'attribut -Force, puis tout fonctionnait.
Enable-Migrations -ProjectName -StartupProjectName --ConnectionStringName -Force
Dans mon cas, c’est parce que j’avais ajouté un contexte secondaire, «ApplicationDbContext», dans le cadre de l’identité ASP.net. Lorsque j'ai à nouveau exécuté la commande 'enable-migrations', j'ai eu une erreur indiquant qu'il y avait plus d'un contexte. Une fois que j'ai combiné les deux choses ont commencé à fonctionner à nouveau.