Я переношу с 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()));
для меня это, кажется, пропустит контекстную инициализацию:
UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>());
должен быть
UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()));
У меня была такая же проблема. Я занимаюсь разработкой базы данных с помощью файла 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")
{
}
}
Моя проблема заключалась в том, что я попытался использовать сгенерированную строку соединения 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" />
Если вы сначала используете код, проверьте свою строку соединения, чтобы гарантировать, что имя поставщика является "SqlClient", как в providerName = "System.Data.SqlClient
Если вы сначала используете базу данных, проверьте свою строку подключения, чтобы гарантировать, что имя поставщика является "EntityClient", как в providerName = "System.Data.EntityClient
Я также получил это сообщение об ошибке, но причина и решение были разными. В моем случае я ввел новое свойство Id типа Guid в классе ApplicationUser. Совершенно допустимый синтаксис С#, но, по-видимому, он создал огромную путаницу для ядра Identity или EntityFramework, которое опирается на размышления, чтобы найти материал.
Удаление нового свойства Id в моем классе ApplicationUser разрешило эту ошибку.
Я столкнулся с этой проблемой, и это был конфликт имен объектов. 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)
{
}
Моя проблема заключалась в том, что я создал новый DbContext, но он не наследовался от IdentityDbContext.
Легкое исправление...
public partial class GoldfishDbContext : IdentityDbContext<ApplicationUser>
{
....
}
Я не уверен, почему это происходит, мое решение работает отлично, проверил все перед сном. Через 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" />
Та же проблема для меня, она решается с помощью этого кода:
public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false)
{
Database.Connection.ConnectionString = @"data source=...;initial catalog=...;user id=...;password=...;multipleactiveresultsets=True;application name=EntityFramework";
}
Это произошло со мной, потому что я пытался подключить 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;
}
}