Задайте свойство 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())))
{
}