2014-10-05 2 views
0

Я в процессе обновления от простого членства до Identity 2.0 в моем существующем веб-проекте. Некоторые из больших изменений, которые связаны с инфраструктурой сущностей, - это наследование DBContext и UserProfiles, изменяющееся на «Пользователи».История миграции Entity Framework не распознается после обновления Identity 2.0?

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

Ожидается, что после того, как мой код изменится для доступа к Identity 2.0, я добавлю переход, и он сгенерирует изменения схемы в моей папке миграции.

По какой-то причине он больше не распознает существующую таблицу истории миграции в текущем db! Когда я запускаю add-migration, он говорит, что существуют существующие миграции, которые не применяются, и что я должен сначала запустить базу данных обновлений. Я запускаю update-database -script, чтобы увидеть, что он пытался сделать, и он хочет создать таблицу истории миграции и каждую миграцию в моем проекте.

Кажется, что некоторая таблица истории миграции больше не распознается. Я запускал get-migrations, чтобы подтвердить, что он разговаривает с правильной базой данных, и это было, но миграция не применялась.

Запуск Entity Framework 6.1.1

Любые предложения?

internal sealed class Configuration : DbMigrationsConfiguration<Namespace.MyContext> 
{ 
    public Configuration() 
    { 
     AutomaticMigrationsEnabled = true; 
     AutomaticMigrationDataLossAllowed = false; 
    } 

    protected override void Seed(Namespace.MyContext context) 
    { 
     //Stuff to initialize an empty db 
    } 


public class UserProfile : IdentityUser<int, CustomIdentityUserLogin, CustomIdentityUserRole, CustomIdentityUserClaim>, IUser<int> 
{ 
    [Required] 
    public string Name { get; set; } 

    public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<UserProfile, int> manager) 
    { 
     // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType 
     var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie); 
     // Add custom user claims here 
     return userIdentity; 
    } 
    //other properties related to the user profile 

} 

Edit 2:

В качестве теста, я удалил migrationhistory таблицу, побежал "обновление базы данных--targetmigration mostcurrentmigraiton -script", а затем удаляются все изменения в миграционной истории с исключением сценарий, запустил скрипт. Затем я попытался получить миграцию, и не появилось «никаких миграций, примененных к целевой базе данных». Я подтвердил, что он создал таблицу, а версия продукта обновилась для предыдущих миграций, где они были старше. Пожалуйста, помогите!

+0

Пожалуйста, разместите свои 'Configuration/Migrations.cs' и' IdentityModels.cs'. – Yoda

+0

@Yoda Я отредактировал мое сообщение с тем, что вы запросили, спасибо! – Csharpfunbag

ответ

1

Я хотел (а) добавить комментарий, но он зашел слишком долго.

Первый вариант: попробуйте update-database -force в PCM.

Второй вариант:, если это еще не развернуто веб-приложение, и вы не заботитесь о потере данных еще, мой ответ здесь может помочь: Second attempt to generate script sql script did not work

Третий вариант: Существует еще одно, что приходит мне на ум. Если вы создаете новый ASP .NET MVC 5.1 с шаблоном, включая Identity 2.0, вы получаете класс IdentityModels.cs в Models. Это выглядит следующим образом:

namespace WebApplication2.Models { 
    // You can add profile data for the user by adding more properties to your ApplicationUser class, please visit http://go.microsoft.com/fwlink/?LinkID=317594 to learn more. 
    public class ApplicationUser : IdentityUser { 

     PROPERTIES OF APPLICATION USER HERE 


     public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager) { 
      // Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType 
      var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie); 
      // Add custom user claims here 
      return userIdentity; 
     } 
    } 

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser> { 


     public ApplicationDbContext() 
      : base("DefaultConnection", throwIfV1Schema: false) { 
      System.Diagnostics.Debug.WriteLine("CONSTRUCTOR"); 
      Configuration.LazyLoadingEnabled = true; 
      Configuration.ProxyCreationEnabled = true; 
     } 
     //stuff in database 
     public DbSet<Person> Persons { get; set; } 


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

     public static ApplicationDbContext Create() { 

      return new ApplicationDbContext(); 

     } 


    } 
} 

, а затем в Application_Start() в Global.asax у вас есть:

protected void Application_Start() { 


      Database.SetInitializer(new MigrateDatabaseToLatestVersion<ApplicationDbContext, Configuration>()); 
      new ApplicationDbContext().Database.Initialize(true); 
    ...more stuff 
    } 

и ваш код может не хватать эти две строки из Application_Start, но с вашим DbContext (я использовал ApplicationDbContext здесь).

Если это не помогло, извините, у меня нет вариантов.

+0

Варианты 1 и 2 не будут работать для меня, поскольку я могу создать скрипт с обновлением-database -force -script, и все sql есть для каждой миграции моего проекта с самого начала (весь код вверх). Проблема состоит в том, что таблица migistigistory с ее миграциями не распознается командами миграции powershell. IdentityModel в шаблоне 5.1 - это, по сути, пользовательский файл, который предоставляется в предыдущих шаблонах, но гораздо более расширяемый. В этом случае я расширяю userprofile в пользовательский идентификатор, так как я хочу, чтобы мое поле Id было int вместо nvarchar. – Csharpfunbag

+0

Йода, благодарю вас за ваши быстрые ответы! – Csharpfunbag

1

После долгих поисков неисправностей я обнаружил, что проблема связана с безопасностью. Get-Migrations вернет сообщение, которое я видел, когда пароль не вводится в строку соединения, которую использует dbcontext. Интересно, что, используя localdb для разработки, у меня было правильное имя пользователя и пароль, так как база данных обновлений смогла создать новые таблицы, но для доступа к ним не должен быть доступ к некоторому уровню доступа. То, что мне показалось наиболее странным, заключается в том, что при переходе на миграцию не было сказано, что существует проблема с учетными данными!

+1

У меня была аналогичная проблема: запуск 'Get-Migrations' помог мне разобраться в первопричине, которая изменила мой проект« run »моего решения. По-видимому, строка подключения считывается из текущего проекта, который выполняется для решения, тогда как сами миграции считываются из текущего проекта консоли диспетчера пакетов. –

Смежные вопросы