Le type d’entité ApplicationUser ne fait pas partie du modèle pour le contexte actuel

Je migre d’Identity 1.0.0 vers Identity 2.0.1 en suivant cet article

et le code de migration généré n’est rien à propos du nouvel IdentityUser. Il n’ajoute pas les nouvelles colonnes.

J’ai donc fait un nouveau projet et essayé à nouveau, mais les codes de migration sont vides.

Pour résoudre ce problème, j’ai effectué les modifications directement dans SQL Server et importé à nouveau ma firebase database dans ma solution.

Maintenant, mon AspNetUser est exactement le même que mon IdentityUser comme vous pouvez le voir

IdentityUser

 public virtual int AccessFailedCount { get; set; } public virtual ICollection Claims { get; } public virtual ssortingng 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 ssortingng PasswordHash { get; set; } public virtual ssortingng PhoneNumber { get; set; } public virtual bool PhoneNumberConfirmed { get; set; } public virtual ICollection Roles { get; } public virtual ssortingng SecurityStamp { get; set; } public virtual bool TwoFactorEnabled { get; set; } public virtual ssortingng 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 ssortingng Id { get; set; } [Required] [SsortingngLength(256)] public ssortingng UserName { get; set; } public ssortingng PasswordHash { get; set; } public ssortingng SecurityStamp { get; set; } [SsortingngLength(256)] public ssortingng Email { get; set; } public bool EmailConfirmed { get; set; } public bool Is_Active { get; set; } [Required] [SsortingngLength(128)] public ssortingng Discriminator { get; set; } public int? user_type_id { get; set; } public bool Has_accepted_policy { get; set; } public ssortingng 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 

et quand j’essaie d’enregistrer un utilisateur, j’ai l’exception suivante

Le type d’entité ApplicationUser ne fait pas partie du modèle pour le contexte actuel

à cette ligne

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

Mon startup.Auth.cs

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

Et dans mon AccountController, je déclare mon UserManager comme ceci

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

Je n’ai rien changé sauf les nouvelles propriétés de la classe AspNetUser et cela fonctionnait bien avant la migration.

Il y a un problème similaire sur CodePlex marqué comme fixe mais ils ne donnent pas la solution

Est-ce que quelqu’un sait comment réparer ceci?

MODIFIER

Pour être sûr que je n’ai pas fait d’erreurs lorsque j’ai édité ma firebase database SQL. J’ai créé un autre projet et généré une firebase database d’identité et j’ai modifié la chaîne de connexion pour cette firebase database et j’ai toujours la même erreur.

SOLUTION

Lorsque j’ai édité ma firebase database, je n’ai pas remarqué que dans Identity 2.0.0, ils avaient modifié le User_Id for UserId dans la table AspUserClaims . Après avoir fait cela, j’ai eu la même erreur mais j’ai ensuite fait ce que tschmit007 a dit à propos de l’ajout d’ ApplicationDbContext au constructeur UserStore et maintenant ça marche.

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

pour moi, il semble manquer une instanciation de contexte:

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

devrait être

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

J’avais le même problème. Je fais d’abord du développement de firebase database avec un fichier EDMX.
Si vous utilisez la chaîne de connexion générée lors de l’ajout du fichier EDMX dans :base(“EDMXConnSsortingng”) vous rencontrerez probablement ce problème.

J’ai résolu ce problème en créant une chaîne de connexion standard qui pointe vers la firebase database où se trouvent les tables d’identité ASP.NET.

  

Et puis utilisé cette chaîne de connexion dans :base , et cela a fonctionné!

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

Mon problème était que j’ai essayé d’utiliser la chaîne de connexion ADO.NET générée pour le contexte généré et d’authentification ApplicationDbContext . Je l’ai corrigé en utilisant une chaîne de connexion distincte pour l’authentification. Faites également attention au fournisseur – pour le contexte d’authentification, il doit s’agir de System.Data.SqlClient :

  

Si vous utilisez d’abord le code, vérifiez votre chaîne de connexion pour vous assurer que providerName est “SqlClient” comme dans providerName = “System.Data.SqlClient

Si vous utilisez d’abord la firebase database, vérifiez votre chaîne de connexion pour vous assurer que NomServeur est “EntityClient” comme dans providerName = “System.Data.EntityClient

J’ai également reçu ce message d’erreur, mais la cause et la solution étaient différentes. Dans mon cas, j’avais introduit une nouvelle propriété Id de type Guid dans ma classe ApplicationUser. Une syntaxe C # parfaitement valide, mais elle a apparemment créé une confusion massive pour le kernel Identity ou EntityFramework qui repose sur la reflection pour trouver des éléments.

La suppression de la nouvelle propriété Id dans ma classe ApplicationUser a résolu cette erreur.

J’ai rencontré ce problème et c’était un conflit de nom d’object. IdentityConfig.cs utilisait ApplicationUser, mais il utilisait IdentityModels.ApplicationUser généré automatiquement au lieu de DataAccess.ApplicationUser de mon propre contexte. Fait parfaitement logique une fois que je l’ai trouvé. J’ai donc supprimé IdentityModels.cs généré automatiquement à partir du modèle WebAPI de base – ne l’utilisant plus de toute façon – puis j’ai ajouté l’instruction using dans IdentityConfig.cs à mon propre espace de noms DataAccess et voilà, un mappage correct. Si vous oubliez que le gabarit a généré beaucoup de choses pour vous, vous rencontrerez le problème suivant:

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

Mon problème était que j’avais créé un nouveau DbContext, mais il n’héritait pas d’IdentityDbContext.

Une solution facile …

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

Je ne suis pas sûr que cela se produise, ma solution fonctionne parfaitement, a tout testé avant de dormir. Après 12 heures, je l’ai vérifié à nouveau et j’ai exécuté exactement la même erreur. J’ai essayé presque toutes les solutions ici dans SO mais aucune ne fonctionne.

J’implémente une approche de firebase database ici. Puis tout à coup il y avait ce

DefaultConnection

sur mon web.config que Visual Studio a généré lorsque j’ai créé la solution pour la première fois. Je l’ai donc utilisé à la place de la chaîne de connexion générée par mon fichier EDMX et soudain ça marche!

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

C’était ma chaîne de connexion qui fonctionne:

  

A l’origine, j’utilise ce qui a été généré par mon fichier EDMX mais soudain, le site ne fonctionne pas bien que cela fonctionne avant. Je n’ai rien changé et tout le code était dans TFS, donc je suis sûr à 100% qu’il fonctionne et j’ai effectué une restauration complète et obtenu la dernière version:

  

Cela m’est arrivé parce que j’essayais de connecter ApplicationUserManager et d’autres dépendances connexes en utilisant mon conteneur d’dependency injection. Dans certains cas, le conteneur a résolu ApplicationDbContext dans d’autres cas, l’injecteur intégré d’Owan l’a résolu.

La manière la plus simple de s’assurer que cela ne se produit pas est de ne pas connecter l’un des éléments Auth à l’aide du conteneur DI de votre choix, sauf si vous savez vraiment ce que vous faites avec DI … en injecteur.

En d’autres termes, supprimez tout ce qui suit:

  builder.RegisterType().InstancePerRequest(); 

Et laissez Owin le résoudre comme il a été construit:

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