Задайте свойство ASP.NET Identity ConnectionString в .NET 4.5.1
Итак, в основном после окончательного обучения как изменить OpenAuth, чтобы не использовать DefaultConnection в .NET 4.5, я перешел к 4.5.1, сделав эти исследования спорными. Обязанности AuthConfig.cs теперь находятся в Startup.Auth.cs, статические методы OpenAuth были абстрагированы, и поэтому я больше не могу изменять значение по умолчанию OpenAuth.ConnectionString напрямую.
Какова наилучшая практика для изменения строки/базы данных соединения в .NET 4.5.1?
Ответы
Ответ 1
Кандидат на освобождение
Работает с Microsoft.AspNet.Identity.EntityFramework 1.0.0-rc1
В конструкторе без параметров для AccountController измените строку
IdentityManager = new AuthenticationIdentityManager(new IdentityStore());
к
IdentityManager = new AuthenticationIdentityManager(new IdentityStore(new DefaultIdentityDbContext("YourNameOrConnectionString")));
и вам хорошо идти.
Release
Работает с Microsoft.AspNet.Identity.EntityFramework 1.0.0
Подобно тому, что мы делали для кандидата на выпуск, но мы делаем это в другом месте. Откройте IdentityModels.cs
, который был создан как часть шаблона VS, и добавьте следующий конструктор в класс ApplicationDbContext
:
public ApplicationDbContext(string nameOrConnectionString)
: base(nameOrConnectionString)
{
}
и теперь вы можете изменить конструктор без параметров в AccountController
из
public AccountController()
: this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext())))
{
}
to
public AccountController()
: this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext("YourNameOrConnectionString"))))
{
}
и ваш результат.
Ответ 2
Я придерживался предложенного вами подхода, и это сработало для меня. Однако было несколько вещей, в основном синтаксических и назвавших проблемы, которые оказались разными. Я думаю, что эти различия связаны, вероятно, с разными версиями Visual Studios, которые мы использовали (а не с .NET - моя версия выпускается с .NET 4.5.1). Я продолжаю описывать свое конкретное решение.
Моя цель состояла в том, чтобы иметь один контекст БД, с которым я могу получить доступ как к данным, связанным с пользователем, так и к удостоверениям, а также к моим пользовательским данным приложения. Для этого я полностью удалил класс ApplicationDbContext
, который автоматически создается для вас при создании нового проекта.
Затем я создал новый класс MyDbContext
.
public class MyDbContext: DbContext
{
public MyDbContext() : base("name=DefaultConnection")
{
}
//
// These are required for the integrated user membership.
//
public virtual DbSet<IdentityRole> Roles { get; set; }
public virtual DbSet<ApplicationUser> Users { get; set; }
public virtual DbSet<IdentityUserClaim> UserClaims { get; set; }
public virtual DbSet<IdentityUserLogin> UserLogins { get; set; }
public virtual DbSet<IdentityUserRole> UserRoles { get; set; }
public DbSet<Movie> Movies { get; set; }
public DbSet<Order> Orders { get; set; }
public DbSet<Purchase> Purchases { get; set; }
}
Поля Roles
, Users
, UserClaims
, UserLogins
, UserRoles
являются такими, какие были предложены для управления членством. Однако в моем случае их типы имеют разные имена (ApplicationUser
вместо User
, IdentityUserClaim
вместо UserClaim
и т.д.). Полагаю, именно по этой причине у Antevirus была проблема "Пользователь не найден".
Кроме того, как мы видим, в моем случае есть 5 таких полей, а не 8. Вероятно, это связано с различными версиями Visual Studio.
Последнее изменение, которое я сделал, было в классе AccountController
и отражает использование нового контекста MyDbContext
. Здесь я передал экземпляр MyDbContext
вместо ApplicationDbContext
Перед
public AccountController()
: this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext())))
{
}
После
public AccountController()
: this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new MyDbContext())))
{
}