J'ai une base de données locale qui est actuellement dans sa deuxième version et devrait maintenant aller à sa troisième version.
Le code des migrations précédentes a été généré par un autre programmeur, je suppose donc que je fais quelque chose de mal ici.
Dans mon modèle, il y a environ 30 classes et dans le dossier du modèle, il y a un dossier de mappage qui contient les mappages de ces 30 classes.
Alors maintenant, j'ai ajouté une nouvelle classe de la même manière que les classes précédentes, puis j'ai exécuté la commande add-migration dans la console Package Manager.
Malheureusement, la méthode de migration Up () et Down () est vide.
Lorsque je regarde dans la base de données, il existe une __migrationHistory disponible avec les 2 migrations précédentes. Si j'exécute mon application maintenant, la troisième migration est également ajoutée, mais il est évident que la nouvelle table n'est pas créée car elle ne fait pas partie de la méthode Up ().
Que pourrais-je faire de mal?
Je pense que quelque chose ne va pas lors de l'échafaudage des migrations précédentes ... C'est comme s'il ne pouvait pas trouver les nouvelles classes Code-First que j'ai ajoutées.
Ceci est ma commande:
add-migration "1.2" -verbose -ProjectName "MyEFproject"
Je suppose que les échafaudages ne savent pas où chercher la nouvelle classe ... ou est-ce par convention que toutes les classes de modèles doivent simplement figurer dans le projet?
Résultat de add-migration:
namespace MyProject.Migrations
{
using System;
using System.Data.Entity.Migrations;
public partial class _1002 : DbMigration
{
public override void Up()
{
}
public override void Down()
{
}
}
}
Exemple de nouvelle classe de modèle:
using System;
using System.Collections.Generic;
namespace MyProject.Models
{
public partial class MyTable
{
public string SomeId { get; set; }
public string SomeText { get; set; }
}
}
Exemple de nouvelle classe de cartographie
using System.ComponentModel.DataAnnotations.Schema;
using System.Data.Entity.ModelConfiguration;
namespace MyProject.Models.Mapping
{
public class MyTableMap : EntityTypeConfiguration<MyTable>
{
public MyTableMap()
{
// Primary Key
this.HasKey(t => t.SomeId);
// Properties
this.Property(t => t.SomeText)
.IsRequired()
.HasMaxLength(30);
// Table & Column Mappings
this.ToTable("MyTable", "database");
this.Property(t => t.SomeId).HasColumnName("SomeId");
this.Property(t => t.SomeText).HasColumnName("SomeText");
}
}
}
Je vous remercie,
Vous devez ajouter votre table à votre implémentation de la classe DbContext
, par exemple.
public class MyDatabaseEntities : DbContext {
public virtual DbSet<MyTable> MyTable { get; set; }
}
J'ai pu résoudre ce problème en supprimant un enregistrement de la dernière migration de la table _MigrationHistory . Cet enregistrement avait été créé de manière incorrecte avant que j'ajoute DbSet pour le nouvel objet de modèle à la classe DbContext . Après cette suppression, une nouvelle migration était créée avec corriger les méthodes Up () et Down ().
J'ai eu ce problème parce que j'ai oublié d'ajouter {get; set;} après mes noms de variables
Dans mon cas, le projet datacontext est un projet de classe lib. C'est différent du projet de démarrage qui est asp.net mvc 5 project. Or, par erreur, la chaîne de connexion du projet de démarrage pointe vers une base de données différente.
Assurez-vous donc que le projet datacontext et le projet de démarrage pointent sur la même base de données. Utilisez également la commande complète mentionnée dans la question, comme suit. Vous pouvez également inclure -Force.
add-migration "InitialMigration" -verbose -ProjectName "MyEFproject" -Force
Dans mon cas, je faisais une migration où j'ajoutais des champs à une table existante et finissais avec des méthodes Up
et Down
vides
J'ai eu quelque chose comme ça:
public bool ExistingField { get; set; }
bool NewField { get;set; }
Pouvez-vous repérer la différence ...?
Si vous faites cette erreur, relancez la migration avec le même nom (vous devrez probablement ajouter le paramètre -Force
pour l'échafauder complètement).
PS. Assurez-vous toujours que votre projet est entièrement construit avant d'essayer de faire n'importe quel type de commande EF. Si votre projet ne se construit pas déjà, vous vous posez des problèmes.
Lors de la restauration d'un contexte EF Core Data existant, les migrations ne sont générées que lorsque j'ai supprimé la variable ApplicationDbContextModelSnapshot
accompagnant les migrations.
Cette classe est générée automatiquement et doit s'aligner sur votre niveau de migration actuel.
Je devais mettre à jour la base de données avec la dernière migration avant la vide ajoutant ce paramètre -TargetMigration:"{your-migration-name}"
.
Cela vous indiquera probablement qu'il y aura une perte de données lors du prochain buggy que nous avons essayé. Si vous pouvez vous le permettre, ajoutez-y -Force
.
Ensuite, j'ai essayé d'ajouter mon nouveau Add-Migration
et ce n'était pas vide.
La dernière chose que vous devrez peut-être faire si l’exception ci-dessus est levée est d’utiliser SQL Server Management Studio, de supprimer le dernier Automatic migration
et d’essayer de l’ajouter à nouveau.
J'obtenais des migrations vides ajoutées lorsque j'avais associé par erreur deux tables en utilisant une relation à plusieurs plutôt que plusieurs (c'est-à-dire que j'avais oublié l'une des propriétés de navigation). J'avais un fichier d'amorçage qui attendait beaucoup de relations et échouait par la suite lors de la migration, ce qui entraînait l'échec de la migration. Malheureusement, aucun résultat ne rendait évident le problème et ce n’est qu’en utilisant le Entity Framework Power Tools (v4 mais installé dans VS2015) j’aperçois visuellement la relation incorrecte et réalise que c’est probablement la cause.
J'ai eu ce problème précis après avoir voulu ajouter une colonne supplémentaire à ma base de données. Parce que mes données ne seraient pas stockées à moins que les tables ne soient vides, j'ai supprimé toutes les tables et les migrations pour recréer les tables. Lorsque j'ai essayé de migrer, la migration comportait des méthodes vides de haut en bas.
J'ai résolu le problème en supprimant le fichier d'instantané, car cela créait le problème. J'ai donc supprimé toutes les migrations et le fichier d'instantané, ajouté à nouveau la migration et exécuté la base de données de mise à jour. Les tables et les migrations ont été mises à jour avec succès dans ma nouvelle colonne.
Une meilleure méthode consiste toutefois à exécuter la méthode down et à supprimer les tables de cette manière si vous travaillez sur des données de test. Évidemment, il est mauvais dans le monde réel d'abandonner des tables.