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; } }