Es gibt bereits ein Objekt mit dem Namen 'AspNetRoles' in der Datenbank

Question

Vor einiger Zeit habe ich eine ASP.NET MVC 5-Website mit der Identity 1.0-Version erstellt und die Identity-Tabellen mit diesem Projekt erstellt. Jetzt muss ich andere Website mit der gleichen Datenbank für die Authentifizierung machen, aber jetzt ist die Identity-Version 2.0. Also, wenn ich versuche, auf der neuen Website zu authentifizieren, bekomme ich einige Fehler.

Ich versuche, die Datenbank mit dem Ansatz Migrationen zu migrieren, aber es ist verwirrt und ich bekomme diesen Fehler There is already an object named 'AspNetRoles' in the database., wenn ich Update-Datenbank in der PM-Konsole eingeben.

Meine Frage ist, wie der beste Weg ist, um die gleiche Datenbank für die authetication beiden Stellen (eine mit der 1.0-Version Identität und andere mit 2.0) zu verwenden. Muss ich wirklich die Datenbank migrieren?

Wenn ja, wie kann ich diesen Fehler beheben, den ich bekomme?

Answer 1

Add-Migration InitialMigrations -IgnoreChanges 

Dies sollte eine leere "InitialMigration" -Datei erzeugen. Fügen Sie nun der gewünschten Klasse die gewünschten Änderungen hinzu. Sobald Änderungen hinzugefügt werden, das Update erneut Befehl ausführen:

update-database -verbose 

Nun ist die automatische Migration angewandt wird und die Tabelle wird mit Änderungen geändert werden.

Edit: Hier ist eine Lösung zur Migration Identität 1 bis 2 Upgrading from ASP.NET.Identity 1.0 to 2.0 Verwenden Sie dieses Handbuch Migration

public override void Up() 
    { 
     RenameColumn(table: "dbo.AspNetUserClaims", name: "User_Id", newName: "UserId"); 
     RenameIndex(table: "dbo.AspNetUserClaims", name: "IX_User_Id", newName: "IX_UserId"); 
     DropPrimaryKey("dbo.AspNetUserLogins"); 
     AddColumn("dbo.AspNetUsers", "Email", c => c.String(maxLength: 256)); 
     AddColumn("dbo.AspNetUsers", "EmailConfirmed", c => c.Boolean(nullable: false)); 
     AddColumn("dbo.AspNetUsers", "PhoneNumber", c => c.String()); 
     AddColumn("dbo.AspNetUsers", "PhoneNumberConfirmed", c => c.Boolean(nullable: false)); 
     AddColumn("dbo.AspNetUsers", "TwoFactorEnabled", c => c.Boolean(nullable: false)); 
     AddColumn("dbo.AspNetUsers", "LockoutEndDateUtc", c => c.DateTime()); 
     AddColumn("dbo.AspNetUsers", "LockoutEnabled", c => c.Boolean(nullable: false)); 
     AddColumn("dbo.AspNetUsers", "AccessFailedCount", c => c.Int(nullable: false)); 
     AlterColumn("dbo.AspNetUsers", "UserName", c => c.String(nullable: false, maxLength: 256)); 
     AlterColumn("dbo.AspNetUsers", "FirstName", c => c.String(nullable: false)); 
     AlterColumn("dbo.AspNetUsers", "LastName", c => c.String(nullable: false)); 
     AddColumn("dbo.AspNetUsers", "CreatedDateTime", c => c.DateTime(nullable: false)); 
     AlterColumn("dbo.AspNetRoles", "Name", c => c.String(nullable: false, maxLength: 256)); 
     AddPrimaryKey("dbo.AspNetUserLogins", new[] { "LoginProvider", "ProviderKey", "UserId" }); 
     CreateIndex("dbo.AspNetUsers", "UserName", unique: true, name: "UserNameIndex"); 
     CreateIndex("dbo.AspNetRoles", "Name", unique: true, name: "RoleNameIndex"); 
     DropColumn("dbo.AspNetUsers", "Discriminator"); 
    } 

Answer 2

Während Sie (seit EF6) Migrationen in zwei separaten Projekten für dieselbe Datenbank verwenden können, kann es keine Überschneidungen geben. Die Art der Migration funktioniert über eine dbo._MigrationHistory Tabelle, in der der Kontext gespeichert wird, der die Migration und den Modellstatus Ihrer Anwendung generiert hat, einschließlich der Identitätsmodelle.

Wenn Sie versuchen, Ihre zweite Anwendung zu verbinden, findet sie keine vorherigen Migrationen und muss daher ihre anfängliche Migration generieren, die Tabellen für die Identity-Modelle enthält, die sich ebenfalls in ihrem Kontext befinden. Da ist dein Problem.

Für die Zwecke der Identität müssen Sie ein Projekt auswählen, um den Master zu machen. Dieser verwendet einen Standard IdentityDbContext, in dem die Identity-Modelle migriert werden.

Das andere Projekt muss zu einem Slave gemacht werden, zumindest in Bezug auf die Verwendung von Identity. Daher müssen Sie mit mindestens zwei Kontexten in dieser Anwendung interagieren. Man wird eine Unterklasse von IdentityDbContext sein, aber so behandelt, als Datenbank-first:

public class MyIdentityContext : IdentityDbContext<ApplicationUser> 
{ 
    public MyIdentityContext() 
     : base("ConnectionStringNameForYourSharedDB") 
    { 
     Database.SetInitializer<MyIdentityContext>(null); 
    } 
} 

Der andere Kontext wird nur eine ganz normale DbContext Unterklasse, die als normal migriert. Sie müssen dies für jedes andere Projekt wiederholen, das möglicherweise auf dieselben Identitätsinformationen aus derselben Datenbank zugreifen muss. Aufgrund des repetitiven Codes, der dazu führen wird (und der Tatsache, dass Ihre Klasse ApplicationUser geteilt werden muss), sollten Sie diesen Code in eine Klassenbibliothek verschieben, auf die jedes Projekt verweisen kann.