EntityType 'IdentityUserLogin' не имеет определенного ключа. Определить ключевые для этой атрибутом entitytype

Проблема в том, что ваш ApplicationUser наследует от IdentityUser , который определяется следующим образом:

IdentityUser : IdentityUser<string, IdentityUserLogin, IdentityUserRole, IdentityUserClaim>, IUser
....
public virtual ICollection<TRole> Roles { get; private set; }
public virtual ICollection<TClaim> Claims { get; private set; }
public virtual ICollection<TLogin> Logins { get; private set; }

И их первичные ключи сопоставляются в методе OnModelCreating класса IdentityDbContext:

modelBuilder.Entity<TUserRole>()
            .HasKey(r => new {r.UserId, r.RoleId})
            .ToTable("AspNetUserRoles");

modelBuilder.Entity<TUserLogin>()
            .HasKey(l => new {l.LoginProvider, l.ProviderKey, l.UserId})
            .ToTable("AspNetUserLogins");

И поскольку ваш DXContext не является производным от него, эти ключи не определяются.

Если вы покопаетесь в источниках Microsoft.AspNet.Identity.EntityFramework, вы все поймете.

Я столкнулся с этой ситуацией некоторое время назад, и я найдено три возможных решения (возможно, есть и другие):

1. используйте отдельные DbContexts против двух разных баз данных или одной и той же базы данных, но разных таблиц.
2. объедините свой DXContext с ApplicationDbContext и используйте одну базу данных.
3. используйте отдельные DbContexts для одной и той же таблицы и управляйте их миграциями соответственно.

Вариант 1: Смотрите обновление внизу.

Вариант 2: Вы в конечном итоге получите DbContext, как вот этот:

public class DXContext : IdentityDbContext<User, Role,
    int, UserLogin, UserRole, UserClaim>//: DbContext
{
    public DXContext()
        : base("name=DXContext")
    {
        Database.SetInitializer<DXContext>(null);// Remove default initializer
        Configuration.ProxyCreationEnabled = false;
        Configuration.LazyLoadingEnabled = false;
    }

    public static DXContext Create()
    {
        return new DXContext();
    }

    //Identity and Authorization
    public DbSet<UserLogin> UserLogins { get; set; }
    public DbSet<UserClaim> UserClaims { get; set; }
    public DbSet<UserRole> UserRoles { get; set; }

    // ... your custom DbSets
    public DbSet<RoleOperation> RoleOperations { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
        modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();

        // Configure Asp Net Identity Tables
        modelBuilder.Entity<User>().ToTable("User");
        modelBuilder.Entity<User>().Property(u => u.PasswordHash).HasMaxLength(500);
        modelBuilder.Entity<User>().Property(u => u.Stamp).HasMaxLength(500);
        modelBuilder.Entity<User>().Property(u => u.PhoneNumber).HasMaxLength(50);

        modelBuilder.Entity<Role>().ToTable("Role");
        modelBuilder.Entity<UserRole>().ToTable("UserRole");
        modelBuilder.Entity<UserLogin>().ToTable("UserLogin");
        modelBuilder.Entity<UserClaim>().ToTable("UserClaim");
        modelBuilder.Entity<UserClaim>().Property(u => u.ClaimType).HasMaxLength(150);
        modelBuilder.Entity<UserClaim>().Property(u => u.ClaimValue).HasMaxLength(500);
    }
}

Вариант 3: У вас будет один DbContext, равный варианту 2. Назовем его IdentityContext. И у вас будет другой DbContext, называемый DXContext:

public class DXContext : DbContext
{        
    public DXContext()
        : base("name=DXContext") // connection string in the application configuration file.
    {
        Database.SetInitializer<DXContext>(null); // Remove default initializer
        Configuration.LazyLoadingEnabled = false;
        Configuration.ProxyCreationEnabled = false;
    }

    // Domain Model
    public DbSet<User> Users { get; set; }
    // ... other custom DbSets

    public static DXContext Create()
    {
        return new DXContext();
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();

        // IMPORTANT: we are mapping the entity User to the same table as the entity ApplicationUser
        modelBuilder.Entity<User>().ToTable("User"); 
    }

    public DbQuery<T> Query<T>() where T : class
    {
        return Set<T>().AsNoTracking();
    }
}

Где пользователь:

public class User
{
    public int Id { get; set; }

    [Required, StringLength(100)]
    public string Name { get; set; }

    [Required, StringLength(128)]
    public string SomeOtherColumn { get; set; }
}

С помощью этого решения я сопоставляю entity User с той же таблицей, что и entity ApplicationUser.

Затем, используя миграции Code First, вам нужно будет сгенерировать миграции для IdentityContext и тогда за то, что DXContext, следующий за этим замечательным постом от Shailendra Chauhan: первые миграции кода с несколькими контекстами данных

Вам придется изменить миграцию, созданную для DXContext. Что-то вроде этого в зависимости от того, какие свойства разделяются между ApplicationUser и Пользователем:

        //CreateTable(
        //    "dbo.User",
        //    c => new
        //        {
        //            Id = c.Int(nullable: false, identity: true),
        //            Name = c.String(nullable: false, maxLength: 100),
        //            SomeOtherColumn = c.String(nullable: false, maxLength: 128),
        //        })
        //    .PrimaryKey(t => t.Id);
        AddColumn("dbo.User", "SomeOtherColumn", c => c.String(nullable: false, maxLength: 128));

И затем запуск миграций по порядку (сначала миграций идентичности) из глобального.asax или любое другое место вашего приложения, использующее этот пользовательский класс:

public static class DXDatabaseMigrator
{
    public static string ExecuteMigrations()
    {
        return string.Format("Identity migrations: {0}. DX migrations: {1}.", ExecuteIdentityMigrations(),
            ExecuteDXMigrations());
    }

    private static string ExecuteIdentityMigrations()
    {
        IdentityMigrationConfiguration configuration = new IdentityMigrationConfiguration();
        return RunMigrations(configuration);
    }

    private static string ExecuteDXMigrations()
    {
        DXMigrationConfiguration configuration = new DXMigrationConfiguration();
        return RunMigrations(configuration);
    }

    private static string RunMigrations(DbMigrationsConfiguration configuration)
    {
        List<string> pendingMigrations;
        try
        {
            DbMigrator migrator = new DbMigrator(configuration);
            pendingMigrations = migrator.GetPendingMigrations().ToList(); // Just to be able to log which migrations were executed

            if (pendingMigrations.Any())                
                    migrator.Update();     
        }
        catch (Exception e)
        {
            ExceptionManager.LogException(e);
            return e.Message;
        }
        return !pendingMigrations.Any() ? "None" : string.Join(", ", pendingMigrations);
    }
}

Это таким образом, мои N-уровневые сквозные сущности не наследуются от классов AspNetIdentity, и поэтому мне не нужно импортировать эту структуру в каждый проект, где я их использую.

Извините за пространный пост. Я надеюсь, что он может предложить некоторые рекомендации по этому вопросу. Я уже использовал варианты 2 и 3 в производственных средах.

UPDATE: Expand Option 1

Для последних двух проектов я использовал 1-й вариант: наличие класса AspNetUser, производного от IdentityUser и отдельный пользовательский класс AppUser. В моем случае DbContexts-это IdentityContext и DomainContext соответственно. И я определил идентификатор пользователя приложения следующим образом:

public class AppUser : TrackableEntity
{
    [Key, DatabaseGenerated(DatabaseGeneratedOption.None)]
    // This Id is equal to the Id in the AspNetUser table and it's manually set.
    public override int Id { get; set; }

(TrackableEntity-это пользовательский абстрактный базовый класс, который я использую в переопределенном методе SaveChanges моего контекста DomainContext)

Сначала я создаю AspNetUser, а затем AppUser. Недостатком этого подхода является то, что вы должны гарантировать, что ваша функциональность "CreateUser" является транзакционный (помните, что будет два DbContext, вызывающих SaveChanges отдельно). Использование TransactionScope почему-то не сработало для меня, поэтому я в итоге сделал что-то уродливое, но это работает для меня:

        IdentityResult identityResult = UserManager.Create(aspNetUser, model.Password);

        if (!identityResult.Succeeded)
            throw new TechnicalException("User creation didn't succeed", new LogObjectException(result));

        AppUser appUser;
        try
        {
            appUser = RegisterInAppUserTable(model, aspNetUser);
        }
        catch (Exception)
        {
            // Roll back
            UserManager.Delete(aspNetUser);
            throw;
        }

(пожалуйста, если кто-то придет с лучшим способом выполнения этой части, я буду признателен, если вы прокомментируете или предложите редактировать этот ответ)

Преимущества в том, что вам не нужно изменять миграции, и вы можете использовать любую сумасшедшую иерархию наследования над пользователем приложения не связываясь с AspNetUser . И на самом деле я использую автоматические миграции для моего IdentityContext (контекст, производный от IdentityDbContext):

public sealed class IdentityMigrationConfiguration : DbMigrationsConfiguration<IdentityContext>
{
    public IdentityMigrationConfiguration()
    {
        AutomaticMigrationsEnabled = true;
        AutomaticMigrationDataLossAllowed = false;
    }

    protected override void Seed(IdentityContext context)
    {
    }
}

Этот подход также имеет преимущество в том, чтобы избежать наследования ваших N-уровневых сквозных сущностей от классов AspNetIdentity.