El tipo de entidad ApplicationUser no es parte del modelo para el contexto actual

Estoy migrando de Identity 1.0.0 a Identity 2.0.1 siguiendo este artículo

y el código de migraciones generado no tiene nada que ver con el nuevo IdentityUser. No agrega las nuevas columnas.

Hice un nuevo proyecto y lo intenté de nuevo, pero los códigos de migración están vacíos.

Para solucionar ese problema, hice las ediciones directamente en SQL Server e importé mi base de datos nuevamente en mi solución.

Ahora mi AspNetUser es exactamente lo mismo que mi IdentityUser como puede ver

IdentityUser

 public virtual int AccessFailedCount { get; set; } public virtual ICollection 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 Logins { get; } public virtual string PasswordHash { get; set; } public virtual string PhoneNumber { get; set; } public virtual bool PhoneNumberConfirmed { get; set; } public virtual ICollection 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 { 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 

y cuando bash registrar un usuario tengo la siguiente excepción

El tipo de entidad ApplicationUser no es parte del modelo para el contexto actual

en esta línea

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

Mi startup.Auth.cs

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

Y en mi AccountController declaro mi UserManager como este

 public AccountController() : this(Startup.UserManagerFactory(), Startup.OAuthOptions.AccessTokenFormat) { } public AccountController(UserManager userManager, ISecureDataFormat accessTokenFormat) { UserManager = userManager; AccessTokenFormat = accessTokenFormat; } public UserManager UserManager { get; private set; } 

No he cambiado nada excepto las nuevas propiedades en la clase AspNetUser y solía funcionar bien antes de la migración.

Hay un problema similar en CodePlex marcado como fijo, pero no dan la solución

¿Alguien sabe cómo arreglar esto?

EDITAR

Para estar seguro de que no cometí ningún error cuando edité mi base de datos SQL. Creé otro proyecto y generé una base de datos de Identidad y cambié la cadena de conexión para esa base de datos y todavía tengo el mismo error.

SOLUCIÓN

Cuando User_Id mi base de datos, no me di cuenta de que en Identity 2.0.0 modificaron User_Id para UserId en la tabla AspUserClaims . Después de hacer eso tuve el mismo error pero luego hice lo que dijo tschmit007 sobre agregar ApplicationDbContext al constructor UserStore y ahora funciona.

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

para mí, parece pasar por alto una instanciación de contexto:

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

debiera ser

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

Estaba teniendo el mismo problema. Estoy haciendo el primer desarrollo de la base de datos con un archivo EDMX.
Si está utilizando la cadena de conexión generada al agregar el archivo EDMX en :base(“EDMXConnString”) es muy probable que tenga este problema.

Lo solucioné creando una cadena de conexión estándar que apuntaba a la base de datos donde están las tablas de Identidad de ASP.NET.

  

Y luego usé esa cadena de conexión en :base , ¡y funcionó!

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

Mi problema fue que intenté usar la cadena de conexión ADO.NET generada para el contexto generado y de autenticación ApplicationDbContext . Lo arreglé usando una cadena de conexión separada para la autenticación. También preste atención al proveedor: para el contexto de autenticación, debe ser System.Data.SqlClient :

  

Si está utilizando primero el código, verifique su cadena de conexión para asegurarse de que providerName sea ‘SqlClient’ como en providerName = “System.Data.SqlClient

Si está utilizando la base de datos primero, verifique su cadena de conexión para asegurarse de que providerName sea ‘EntityClient’ como en providerName = “System.Data.EntityClient”.

También recibí este mensaje de error, pero la causa y la solución eran diferentes. En mi caso, introduje una nueva propiedad Id de tipo Guid en mi clase ApplicationUser. Sintaxis de C # perfectamente válida, pero al parecer creó confusión masiva para el núcleo Identity o EntityFramework que se basa en la reflexión para encontrar cosas.

La eliminación de la nueva propiedad Id en mi clase ApplicationUser resolvió este error.

Me encontré con este problema y fue un conflicto de nombre de objeto. IdentityConfig.cs usaba ApplicationUser, pero estaba usando el IdentityModels.ApplicationUser generado automáticamente en lugar del DataAccess.ApplicationUser de mi propio contexto. Tenía perfecto sentido una vez que lo encontré. Por lo tanto, eliminé los IdentityModels.cs autogenerados de la plantilla base de WebAPI, sin usarlos de todos modos, luego agregué la sentencia using en IdentityConfig.cs a mi propio espacio de nombres de DataAccess y voila, la asignación correcta. Si olvida que la plantilla generó mucho de esto para usted, se encontrará con el problema:

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

Mi problema era que había creado un nuevo DbContext, pero no heredaba de IdentityDbContext.

Una solución fácil …

 public partial class GoldfishDbContext : IdentityDbContext { .... } 

No estoy seguro de por qué sucede esto, mi solución funciona perfectamente bien, probé todo antes de dormir. Después de 12 horas, lo revisé nuevamente y corrí y este fue exactamente el mismo error. Intenté casi todas las soluciones aquí en SO, pero ninguna de ellas funciona.

Estoy implementando un enfoque de base de datos aquí. Entonces, de repente, estaba esto

DefaultConnection

en mi web.config que Visual Studio generó cuando creé la solución por primera vez. ¡Así que lo he usado en lugar de la cadena de conexión que generó mi archivo EDMX y de repente funciona!

 public class ApplicationDbContext : IdentityDbContext { public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { } public static ApplicationDbContext Create() { return new ApplicationDbContext(); } } 

Esta fue mi cadena de conexión que funciona:

  

Originalmente estoy usando esto que fue generado por mi archivo EDMX pero de repente el sitio web no funciona aunque funciona antes. No cambié nada y todo el código estaba en TFS, así que estoy 100% seguro de que funciona, hice una restauración completa y obtuve la última versión:

  

Esto me sucedió porque estaba tratando de conectar ApplicationUserManager y algunas otras dependencias relacionadas usando mi contenedor de dependency injection. En algunos casos, el contenedor resolvió ApplicationDbContext; en otros casos, el inyector incorporado en Owin lo resolvería.

La forma más fácil de asegurarse de que esto no ocurra es no tratar de cablear ninguna de las cosas de Auth utilizando su contenedor DI de elección a menos que realmente sepa lo que está haciendo con DI … de lo contrario, deje que Owin lo resuelva utilizando el en el inyector.

En otras palabras, elimine algo como:

  builder.RegisterType().InstancePerRequest(); 

Y solo deje que Owin lo resuelva de la manera en que fue construido:

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