Тип объекта ApplicationUser не является частью модели для текущего контекста

Я переношу с Identity 1.0.0 на Identity 2.0.1, следуя этой статье

и генерируемый код миграции ничего не значит о новом IdentityUser. Он не добавляет новые столбцы.

Итак, я сделал новый проект и снова попробовал, но коды миграции пустые.

Чтобы исправить эту проблему, я сделал изменения непосредственно в SQL Server и снова импортировал мою базу данных в свое решение.

Теперь мой AspNetUser точно такой же, как мой IdentityUser, как вы можете видеть

IdentityUser

public virtual int AccessFailedCount { get; set; }

public virtual ICollection<TClaim> Claims { get; }

public virtual string Email { get; set; }

public virtual bool EmailConfirmed { get; set; }

public virtual TKey Id { get; set; }

public virtual bool LockoutEnabled { get; set; }

public virtual DateTime? LockoutEndDateUtc { get; set; }

public virtual ICollection<TLogin> Logins { get; }

public virtual string PasswordHash { get; set; }

public virtual string PhoneNumber { get; set; }

public virtual bool PhoneNumberConfirmed { get; set; }

public virtual ICollection<TRole> Roles { get; }

public virtual string SecurityStamp { get; set; }

public virtual bool TwoFactorEnabled { get; set; }

public virtual string UserName { get; set; }

IdentityUser.cs

public class ApplicationUser : IdentityUser
{
    public bool Has_accepted_policy { get; set; }
    public int user_type_id { get; set; }
}

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("DefaultConnection")
    {

    }
}

AspNetUser

public string Id { get; set; }

[Required]
[StringLength(256)]
public string UserName { get; set; }

public string PasswordHash { get; set; }

public string SecurityStamp { get; set; }

[StringLength(256)]
public string Email { get; set; }

public bool EmailConfirmed { get; set; }

public bool Is_Active { get; set; }

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

public int? user_type_id { get; set; }

public bool Has_accepted_policy { get; set; }

public string PhoneNumber { get; set; }

public bool PhoneNumberConfirmed { get; set; }

public bool TwoFactorEnabled { get; set; }

public DateTime? LockoutEndDateUtc { get; set; }

public bool LockoutEnabled { get; set; }

public int AccessFailedCount { get; set; }

... other virtual properties 

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

Тип объекта ApplicationUser не является частью модели для текущего контекста

в этой строке

IdentityResult result = await UserManager.CreateAsync(user, model.Password);

Мой startup.Auth.cs

UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>());

И в моем AccountController я объявляю свой UserManager следующим образом

public AccountController()
    : this(Startup.UserManagerFactory(), Startup.OAuthOptions.AccessTokenFormat)
{
}

public AccountController(UserManager<ApplicationUser> userManager,
    ISecureDataFormat<AuthenticationTicket> accessTokenFormat)
{
    UserManager = userManager;
    AccessTokenFormat = accessTokenFormat;
}

public UserManager<ApplicationUser> UserManager { get; private set; }

Я ничего не изменил, кроме новых свойств в классе AspNetUser, и он работал для работы задолго до миграции.

Там аналогичная проблема на CodePlex отмечена как фиксированная, но они не дают решение

Кто-нибудь знает, как это исправить?

ИЗМЕНИТЬ

Конечно, я не делал ошибок при редактировании базы данных SQL. Я создал другой проект и создал базу данных Identity, и я изменил строку подключения для этой базы данных, и я все еще имею ту же ошибку.

Решение

Когда я редактировал свою базу данных, я не заметил, что в Identity 2.0.0 они изменили таблицу User_Id для UserId в AspUserClaims. После этого у меня была такая же ошибка, но затем я сделал то, что tschmit007 сказал о добавлении конструктора ApplicationDbContext в конструктор UserStore, и теперь он работает.

UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()));

Ответ 1

для меня это, кажется, пропустит контекстную инициализацию:

UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>());

должен быть

UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()));

Ответ 2

У меня была такая же проблема. Я занимаюсь разработкой базы данных с помощью файла EDMX.
Если вы используете строку подключения, сгенерированную при добавлении файла EDMX в :base("EDMXConnString") вас, скорее всего, возникнет эта проблема.

Я исправил это, создав стандартную строку подключения, которая указала на базу данных, в которой находятся таблицы удостоверений ASP.NET.

<add name="MyConnString" connectionString="Data Source=server; Initial Catalog=db_name; User ID=user_id; Password=password; Connect Timeout=60;" providerName="System.Data.SqlClient" />

А затем использовал эту строку подключения в :base, и это сработало!

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("MyConnString")
    {
    }
}

Ответ 3

Моя проблема заключалась в том, что я попытался использовать сгенерированную строку соединения ADO.NET для сгенерированного и аутентификационного контекста ApplicationDbContext. Я исправил его, используя отдельную строку подключения для аутентификации. Также обратите внимание на поставщика - для контекста аутентификации он должен быть System.Data.SqlClient:

<add name="DefaultConnection" connectionString="Server=qadb.myserver.com;Database=mydb;User Id=myuser;Password=mypass;" providerName="System.Data.SqlClient" />

Ответ 4

Если вы сначала используете код, проверьте свою строку соединения, чтобы гарантировать, что имя поставщика является "SqlClient", как в providerName = "System.Data.SqlClient

Если вы сначала используете базу данных, проверьте свою строку подключения, чтобы гарантировать, что имя поставщика является "EntityClient", как в providerName = "System.Data.EntityClient

Ответ 5

Я также получил это сообщение об ошибке, но причина и решение были разными. В моем случае я ввел новое свойство Id типа Guid в классе ApplicationUser. Совершенно допустимый синтаксис С#, но, по-видимому, он создал огромную путаницу для ядра Identity или EntityFramework, которое опирается на размышления, чтобы найти материал.

Удаление нового свойства Id в моем классе ApplicationUser разрешило эту ошибку.

Ответ 6

Я столкнулся с этой проблемой, и это был конфликт имен объектов. IdentityConfig.cs использовал ApplicationUser, но вместо собственного контекста DataAccess.ApplicationUser он использовал автоматически сгенерированный IdentityModels.ApplicationUser. Сделал идеальный смысл, как только я его нашел. Таким образом, я удалил автоматически сгенерированный IdentityModels.cs из базового шаблона WebAPI, но в любом случае не использовал его, а затем добавил оператор using в IdentityConfig.cs в свое собственное пространство имен DataAccess и правильное отображение. Если вы забудете шаблон, построенный для этого много, вы столкнетесь с проблемой:

public class ApplicationUserManager : UserManager<ApplicationUser> // the name conflict
{
    public ApplicationUserManager(IUserStore<ApplicationUser> store)
        : base(store)
    {
    }

Ответ 7

Моя проблема заключалась в том, что я создал новый DbContext, но он не наследовался от IdentityDbContext.

Легкое исправление...

public partial class GoldfishDbContext : IdentityDbContext<ApplicationUser>
{
 ....
}

Ответ 8

Я не уверен, почему это происходит, мое решение работает отлично, проверил все перед сном. Через 12 часов я снова проверил и запустил, и это была точно такая же ошибка. Я попробовал почти все решения здесь, в SO, но ни одно из них не работает.

Я реализую подход базы данных здесь. Затем внезапно произошло это

DefaultConnection

в моем файле web.config, сгенерированном Visual Studio при первом создании решения. Поэтому я использовал его вместо строки подключения, сгенерированной моим файлом EDMX, и вдруг это работает!

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("DefaultConnection", throwIfV1Schema: false)
    {
    }

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

Это была моя строка подключения, которая работает:

<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\aspnet-System.WEB-20180718085411.mdf;Initial Catalog=aspnet-System.WEB-20180718085411;Integrated Security=True" providerName="System.Data.SqlClient" />

Первоначально я использую это, которое было сгенерировано моим файлом EDMX, но внезапно веб-сайт не работает, хотя он работает раньше. Я ничего не изменил, и весь код был в TFS, поэтому я на 100% уверен, что он работает, и я сделал полное восстановление и получил последнюю версию:

<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\aspnet-System.WEB-20180718085411.mdf;Initial Catalog=aspnet-System.WEB-20180718085411;Integrated Security=True" providerName="System.Data.SqlClient" />

Ответ 9

Та же проблема для меня, она решается с помощью этого кода:

public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false)
{
    Database.Connection.ConnectionString = @"data source=...;initial catalog=...;user id=...;password=...;multipleactiveresultsets=True;application name=EntityFramework";
}

Ответ 10

Это произошло со мной, потому что я пытался подключить ApplicationUserManager и некоторые другие связанные зависимости, используя контейнер для инъекций зависимостей. В некоторых случаях контейнер разрешил ApplicationDbContext, в других случаях встроенный инжектор в Owin разрешил его.

Самый простой способ убедиться, что этого не происходит, - не пытаться подключить какой-либо материал Auth, используя ваш контейнер DI, если вы действительно не знаете, что вы делаете с DI... иначе просто разрешите Owin его решить используя встроенный инжектор.

Другими словами, удалите что-нибудь вроде:

 builder.RegisterType<ApplicationUserManager>().InstancePerRequest();

И просто пусть Owin разрешит его так, как он был встроен:

 public ApplicationUserManager UserManager
    {
        get
        {
            return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
        }
        private set
        {
            _userManager = value;
        }
    }