La migration EF montre les méthodes empty Up() Down()
J'ai une base de données locale qui est actuellement dans sa deuxième version et doit maintenant aller à sa troisième version.
Le code des migrations précédentes a été généré par un autre programmeur, donc je suppose que je fais quelque chose de mal ici.
Dans mon modèle, il y a environ 30 classes, et à l'intérieur du dossier du modèle, il y a un dossier de mappage et il contient les mappages pour ces 30 classes.
Alors maintenant j'ai ajouté 1 nouvelle classe de la même manière que ces classes précédentes et ensuite exécutez la commande add-migration dans la Console du Gestionnaire de paquets.
Malheureusement, je reçois une migration vide up() et Down () méthode.
Quand je regarde dans la base de données, il y a un _ _ migrationHistory disponible avec les 2 migrations précédentes. Si je lance mon application maintenant, la troisième migration est également ajoutée mais évidemment la nouvelle table n'est pas créée car elle n'est pas dans la méthode Up ().
Que pourrais-je faire de mal?
Je pense que quelque chose ne va pas lors de l'échafaudage les migrations précédentes... C'est comme s'il ne pouvait pas trouver les nouvelles classes de code que J'ai ajoutées.
Ceci est ma commande:
add-migration "1.2" -verbose -ProjectName "MyEFproject"
Je suppose que l'échafaudage ne sait pas où chercher la nouvelle classe... ou est-ce par convention que toutes les classes de modèle sont simplement attendues dans le projet?
Résultat de la migration add:
namespace MyProject.Migrations
{
using System;
using System.Data.Entity.Migrations;
public partial class _1002 : DbMigration
{
public override void Up()
{
}
public override void Down()
{
}
}
}
Échantillon de la 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");
}
}
}
Merci,
9 réponses
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é incorrectement créé avant que J'ajoute DbSet pour un nouvel objet modèle à la classe DbContext. Après cette suppression, une nouvelle migration a été créée avec les méthodes Up() et Down() correctes.
Dans mon cas, le projet datacontext est un projet LIB de classe. Il est différent du projet de démarrage qui est asp.net projet mvc 5. Maintenant, par erreur, la chaîne de connexion dans le 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 vers la même base de données. Utilisez également la commande complète comme mentionné dans la question comme suit. Vous pouvez également inclure-Force.
add-migration "InitialMigration" -verbose -ProjectName "MyEFproject" -Force
J'ai eu ce problème parce que j'ai oublié d'ajouter {get; set;} après mes noms de variables
Aussi: assurez-vous que les nouvelles propriétés que vous avez ajoutées sont publiques!
Dans mon cas, je faisais une migration où j'ajoutais des champs à une table existante et me retrouvais avec des méthodes Up et Down vides,
J'avais quelque chose comme ceci:
public bool ExistingField { get; set; }
bool NewField { get;set; }
Pouvez-vous repérer la différence...?
Si vous faites cette erreur, réexécutez la migration avec le même nom (vous devrez probablement ajouter le paramètre -Force pour l'échafauderplein).
PS. Assurez-vous toujours que votre le projet se construit complètement avant d'essayer de faire n'importe quel type de commande EF. Si votre projet ne se construit pas déjà, vous demandez des ennuis.
Tout en ramenant un contexte de données EF Core existant à vide, mes migrations ne seraient pas générées tant que je n'aurais pas supprimé le ApplicationDbContextModelSnapshot qui accompagnait les migrations.
Cette classe est générée automatiquement et doit s'aligner sur votre niveau de migration actuel.
Je recevais des migrations vides ajoutées quand j'avais lié par erreur deux tables en utilisant une relation 1-many plutôt qu'un many-many (c'est-à-dire que j'ai oublié l'une des propriétés de navigation). J'avais un fichier d'ensemencement qui attendait une relation beaucoup-beaucoup et qui échouait par la suite pendant la migration provoquant l'échec de la migration. Malheureusement, il n'y avait pas de sortie qui rendait évident que c'était le problème et c'était seulement en utilisant les outils électriques Entity Framework (v4 mais installé dans VS2015) Ai-je visuellement vu la relation incorrecte et réalisé que c'était probablement la cause.
J'ai eu ce problème exact après avoir voulu ajouter une colonne supplémentaire à ma base de données. Parce que mes données ne seraient pas semées à moins que les tables soient vides, j'ai supprimé toutes les tables et les migrations pour recréer les tables. Quand j'ai essayé de migrer, la migration avait des méthodes vides de haut en bas.
J'ai résolu cela 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é la migration à nouveau et exécuté la base de données de mise à jour. Les tables et les les migrations ont été mises à jour avec succès avec ma nouvelle colonne.
Une meilleure façon de le faire est d'exécuter la méthode et déposer les tables comme ça, si vous travaillez sur des données de test. Évidemment, c'est mauvais dans le monde réel pour laisser tomber les tables.
J'ai dû mettre à jour la base de données avec la dernière migration avant celle vide en ajoutant ce paramètre -TargetMigration:"{your-migration-name}".
Il vous dira probablement qu'il y aura une perte de données à partir du prochain buggy que nous avons essayé. Si vous pouvez vous le permettre ajoutez -Force pour elle.
, Puis j'ai essayé d'ajouter mon nouveau Add-Migration et il n'était pas vide.
La dernière chose que vous devrez peut-être faire si ci-dessus est de lancer une exception est d'aller à SQL Server Management Studio et de supprimer le dernier Automatic migration et d'essayer de l'ajouter à nouveau.