Bien que cette question soit fondée sur le fait de ne pas se soucier des données, la maintenance des données est parfois essentielle.
Si tel est le cas, j'ai écrit une liste d'étapes sur la façon de récupérer du cauchemar d'Entity Framework lorsque la base de données contient déjà des tables du même nom ici: Comment récupérer du cauchemar d'Entity Framework - la base de données a déjà des tables du même nom
Apparemment ... un modérateur a jugé bon de supprimer mon message, je vais donc le coller ici:
Comment récupérer du cauchemar Entity Framework - la base de données a déjà des tables avec le même nom
Description : Si vous êtes comme nous lorsque votre équipe est nouvelle dans EF, vous vous retrouverez dans un état dans lequel vous ne pouvez pas créer une nouvelle base de données locale ou vous ne pouvez pas appliquer de mises à jour à votre base de données de production. Vous voulez revenir à un environnement EF propre, puis vous en tenir aux bases, mais vous ne pouvez pas. Si vous le faites fonctionner pour la production, vous ne pouvez pas créer une base de données locale, et si vous le faites fonctionner pour le local, votre serveur de production se désynchronise. Et enfin, vous ne souhaitez supprimer aucune donnée du serveur de production.
Symptôme : impossible d'exécuter Update-Database car il essaie d'exécuter le script de création et la base de données contient déjà des tables portant le même nom.
Message d'erreur: System.Data.SqlClient.SqlException (0x80131904): il existe déjà un objet nommé «» dans la base de données.
Contexte du problème : EF comprend où se trouve la base de données actuelle par rapport à l'endroit où se trouve le code en fonction d'une table dans la base de données appelée dbo .__ MigrationHistory. Quand il regarde les scripts de migration, il essaie de reconsidérer où il était en dernier avec les scripts. Si ce n'est pas le cas, il essaie simplement de les appliquer dans l'ordre. Cela signifie qu'il revient au script de création initial et si vous regardez la toute première partie de la commande UP, ce sera le CreeateTable de la table sur laquelle l'erreur s'est produite.
Pour comprendre cela plus en détail, je vous recommande de regarder les deux vidéos référencées ici:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Solution : ce que nous devons faire est de faire croire à EF que la base de données actuelle est à jour sans appliquer ces commandes CreateTable. Dans le même temps, nous voulons toujours que ces commandes existent afin de pouvoir créer de nouvelles bases de données locales.
Étape 1: Nettoyage de la base de données de production
Tout d'abord, effectuez une sauvegarde de votre base de données de production. Dans SSMS, cliquez avec le bouton droit de la souris sur la base de données, sélectionnez "Tâches> Exporter l'application au niveau des données ..." et suivez les invites. Ouvrez votre base de données de production et supprimez / supprimez la table dbo .__ MigrationHistory.
Étape 2: Nettoyage de l'environnement local
Ouvrez votre dossier de migrations et supprimez-le. Je suppose que vous pouvez tout récupérer de git si nécessaire.
Étape 3: recréer l'initiale
Dans le gestionnaire de package, exécutez «Enable-Migrations» (EF vous invitera à utiliser -ContextTypeName si vous avez plusieurs contextes). Exécutez "Add-Migration Initial -verbose". Cela créera le script initial pour créer la base de données à partir de zéro en fonction du code actuel. Si vous aviez des opérations d'amorçage dans la configuration.cs précédente, copiez-la dans l'ensemble.
Étape 4: Trick EF
À ce stade, si nous exécutions Update-Database , nous obtiendrions l'erreur d'origine. Nous devons donc inciter EF à penser qu'il est à jour, sans exécuter ces commandes. Alors, allez dans la méthode Up dans la migration initiale que vous venez de créer et commentez tout.
Étape 5: Update-Database
En l'absence de code à exécuter sur le processus Up, EF créera la table dbo .__ MigrationHistory avec l'entrée correcte pour indiquer qu'il a exécuté ce script correctement. Allez le vérifier si vous le souhaitez. Maintenant, décommentez ce code et enregistrez-le. Vous pouvez réexécuter Update-Database si vous souhaitez vérifier qu'EF pense qu'il est à jour. Il n'exécutera pas l'étape Up avec toutes les commandes CreateTable car il pense que c'est déjà fait.
Étape 6: Confirmez qu'EF est RÉELLEMENT à jour
Si vous aviez du code auquel aucune migration n'avait encore été appliquée, voici ce que j'ai fait ...
Exécutez "Add-Migration MissingMigrations" Cela créera pratiquement un script vide. Comme le code était déjà là, il y avait en fait les commandes correctes pour créer ces tables dans le script de migration initial, donc je viens de couper le CreateTable et les commandes de dépôt équivalentes dans les méthodes Up et Down.
Maintenant, exécutez à nouveau Update-Database et regardez-le exécuter votre nouveau script de migration, en créant les tables appropriées dans la base de données.
Étape 7: Re-confirmez et validez.
Construisez, testez, exécutez. Assurez-vous que tout fonctionne, puis validez les modifications.
Étape 8: Faites savoir au reste de votre équipe comment procéder.
Lorsque la prochaine personne se met à jour, EF ne saura pas ce qui l'a frappé étant donné que les scripts qu'il avait exécutés auparavant n'existent pas. Mais, à supposer que les bases de données locales puissent être époustouflées et recréées, tout cela est bien. Ils devront supprimer leur base de données locale et ajouter à nouveau la création à partir d'EF. S'ils avaient des modifications locales et des migrations en attente, je leur recommanderais de créer à nouveau leur base de données sur le maître, de basculer vers leur branche de fonctionnalités et de recréer ces scripts de migration à partir de zéro.
DROP DATABASEalors ....