EF Migrations génère un fichier de migrations avec des données qui n'existent plus

Question

J'étais sur une branche Spike, jouant avec les migrations EF et une fois que j'ai eu ce que je voulais, j'ai créé la branche dév réelle (basée sur une branche précédente qui n'a aucun code DB ou ORM du tout).

Le nouveau code

J'ai un contexte qui hérite de DbContext avec ce DbSet:

public DbSet<Warehouse> Warehouses { get; set; } 

Et entrepôt contient ceci:

public class Warehouse 
{ 
    public string Code { get; set; } 
    public string Name { get; set; } 
} 

Migrations

Si je lance

add-migration Warehouse 

je reçois un fichier appelé 201708040819010_Warehouse.cs, qui contient ceci:

public override void Up() 
{ 
    RenameTable(name: "dbo.Warehouses", newName: "Warehouse"); 
    DropPrimaryKey("dbo.Warehouse"); 
    AddColumn("dbo.Warehouse", "Code", c => c.String(nullable: false, maxLength: 128)); 
    AlterColumn("dbo.Warehouse", "Name", c => c.String(maxLength: 100)); 
    AddPrimaryKey("dbo.Warehouse", "Code"); 
    CreateIndex("dbo.Warehouse", "Name", unique: true); 
    DropColumn("dbo.Warehouse", "Id"); 
    DropColumn("dbo.Warehouse", "Abbreviation"); 
    DropTable("dbo.People"); 
} 

Ce qui est pas du tout ce que je pensais.

Quel est le problème

Tous les renommages, modifier la colonne et supprimer des colonnes semblent laisser entendre que le flux migratoire est convaincu qu'il doit mettre à jour une table existante dans une db existante.

Mais ce n'est pas vrai, parce que j'ai supprimé mon ancien localdb, je travaille sur une toute nouvelle branche et sur une nouvelle migration.

Pas complètement hors du bleu

Je ne présentent cependant une classe d'entrepôt (lors de la lecture autour de cette branche Spike) qui contenait une carte d'identité, nom et abréviation.

Mais c'est une vieille nouvelle. Et n'existe plus physiquement.

Ce que je soupçonne va sur

Est-ce que Visual Studio trébuche sur lui-même et fonde les nouvelles informations sur les migrations sont stockées dans c'est des dossiers temporaires. J'ai fait un nettoyage de ce qui semblait être lié à this post, mais sans effet positif.

Mise à jour

DbContext

public class MyDbContext : DbContext, IMyDbContext 
{ 
    public MyDbContext() 
     :base("MyDb") 
    { 
     Configuration.LazyLoadingEnabled = false; 
     Database.SetInitializer(new NullDatabaseInitializer<MyDbContext>()); 
    } 

    public DbSet<Warehouse> Warehouses { get; set; } 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     modelBuilder.Configurations 
      .AddFromAssembly(Assembly.GetExecutingAssembly()); 

     modelBuilder.Conventions 
      .AddFromAssembly(Assembly.GetExecutingAssembly()); 
    } 
} 

EF config Migrations

internal sealed class Configuration : DbMigrationsConfiguration<MyDbContext> 
{ 
    public Configuration() 
    { 
     AutomaticMigrationsEnabled = false; 
    } 

    protected override void Seed(MyDbContext context) 
    { 
    } 
} 

Question

Que puis-je faire pour corriger ce comportement (bizarre)?

Answer 1

Je l'ai trouvé. La cause était la suivante:

Je n'ai pas remarqué auparavant parce que vous ne voyez que lorsque vous utilisez -verbose sur update-database. Ce que je ne fais pas à moins que quelque chose ne fonctionne pas (comme maintenant).

Et la raison derrière cela est que pour fonctionner, vous devez avoir un projet de démarrage, qui dans mon cas est mon API REST. Comme il n'a pas de chaîne de connexion (pour le moment), plutôt que de donner une erreur, Migrations suppose que je souhaite utiliser mon instance .\SQLEXPRESS. Comme je ne fournissais pas non plus de connexion sur mon Spike, je travaillais sur SQLEXPRESS sans m'en apercevoir et je vérifiais maintenant par rapport à l'ancienne définition de la table, provoquant ces renames et ces chutes au lieu d'une création propre.

... tout à fait l'hypothèse (agaçante). J'aurais préféré une erreur.