Ik migreer van Identity 1.0.0 naar Identity 2.0.1 na deze artikel
en de gegenereerde migratiecode heeft niets te maken met de nieuwe IdentityUser. De nieuwe kolommen worden niet toegevoegd.
Dus ik heb een nieuw project gemaakt en het opnieuw geprobeerd, maar de migratiecodes zijn leeg.
Om dat probleem op te lossen, deed ik de bewerkingen rechtstreeks in SQL Server en importeerde ik mijn database opnieuw in mijn oplossing.
Mijn AspNetUseris nu precies hetzelfde als mijn IdentityUserzoals je kunt zien
IdentiteitGebruiker
public virtual int AccessFailedCount { get; set; }
public virtual ICollection<TClaim> 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<TLogin> Logins { get; }
public virtual string PasswordHash { get; set; }
public virtual string PhoneNumber { get; set; }
public virtual bool PhoneNumberConfirmed { get; set; }
public virtual ICollection<TRole> 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<ApplicationUser>
{
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
en wanneer ik een gebruiker probeer te registreren, heb ik de volgende uitzondering
Het entiteitstype ApplicationUser maakt geen deel uit van het model voor de huidige context
op deze regel
IdentityResult result = await UserManager.CreateAsync(user, model.Password);
Mijn startup.Auth.cs
UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>());
En in mijn AccountControllerverklaar ik mijn UserManagerals volgt
public AccountController()
: this(Startup.UserManagerFactory(), Startup.OAuthOptions.AccessTokenFormat)
{
}
public AccountController(UserManager<ApplicationUser> userManager,
ISecureDataFormat<AuthenticationTicket> accessTokenFormat)
{
UserManager = userManager;
AccessTokenFormat = accessTokenFormat;
}
public UserManager<ApplicationUser> UserManager { get; private set; }
Ik heb niets veranderd behalve de nieuwe eigenschappen in de klasse AspNetUseren deze werkte goed voor de migratie.
Er is een soortgelijk probleem op CodePlexgemarkeerd als opgelost, maar niet geef de oplossing
Weet iemand hoe dit op te lossen?
BEWERKEN
Om er zeker van te zijn dat ik geen fouten heb gemaakt bij het bewerken van mijn SQL-database. Ik heb een ander project gemaakt en een identiteitsdatabase gegenereerd en ik heb de verbindingsreeks voor die database gewijzigd en ik heb nog steeds dezelfde fout.
OPLOSSING
Toen ik mijn database heb bewerkt, heb ik niet gemerkt dat ze in Identity 2.0.0 de User_Idvoor UserIdin de tabel AspUserClaimshebben gewijzigd . Daarna had ik dezelfde fout, maar toen deed ik wat tschmit007 zei over het toevoegen van de ApplicationDbContextaan de UserStore-constructor en nu werkt het.
UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()));
Antwoord 1, autoriteit 100%
voor mij lijkt het een context-instantie te missen:
UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>());
zou moeten zijn
UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()));
Antwoord 2, autoriteit 98%
Ik had hetzelfde probleem. Ik ontwikkel eerst de database met een EDMX-bestand.
Als u de verbindingsreeks gebruikt die is gegenereerd bij het toevoegen van het EDMX-bestand in :base(“EDMXConnString”), heeft u waarschijnlijk dit probleem .
Ik heb dit opgelost door een standaard verbindingsreeks te maken die verwijst naar de database waar de ASP.NET Identity-tabellen zich bevinden.
<add name="MyConnString" connectionString="Data Source=server; Initial Catalog=db_name; User ID=user_id; Password=password; Connect Timeout=60;" providerName="System.Data.SqlClient" />
En gebruikte toen die verbindingsreeks in :base, en het werkte!
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("MyConnString")
{
}
}
Antwoord 3, autoriteit 20%
Mijn probleem was dat ik probeerde de gegenereerde ADO.NET-verbindingsreeks te gebruiken voor zowel de gegenereerde als de authenticatiecontext ApplicationDbContext. Ik heb het opgelost door een aparte verbindingsreeks te gebruiken voor authenticatie. Let ook op de provider – voor authenticatiecontext moet dit System.Data.SqlClientzijn:
<add name="DefaultConnection" connectionString="Server=qadb.myserver.com;Database=mydb;User Id=myuser;Password=mypass;" providerName="System.Data.SqlClient" />
Antwoord 4, autoriteit 10%
Als u eerst code gebruikt, controleer dan uw verbindingsreeks om er zeker van te zijn dat providerName ‘SqlClient’ is zoals in providerName=”System.Data.SqlClient
Als u eerst de database gebruikt, controleer dan uw verbindingsreeks om er zeker van te zijn dat providerName ‘EntityClient’ is zoals in providerName=”System.Data.EntityClient
Antwoord 5, autoriteit 5%
Ik heb hetzelfde probleem, het is opgelost met deze code:
public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false)
{
Database.Connection.ConnectionString = @"data source=...;initial catalog=...;user id=...;password=...;multipleactiveresultsets=True;application name=EntityFramework";
}
Antwoord 6, autoriteit 2%
Ik kreeg deze foutmelding ook, maar de oorzaak en oplossing waren anders. In mijn geval had ik een nieuwe Id-eigenschap van het type Guid geïntroduceerd in mijn ApplicationUser-klasse. Perfect geldige C#-syntaxis, maar het zorgde blijkbaar voor enorme verwarring voor de Identity- of EntityFramework-kern die afhankelijk is van reflectie om dingen te vinden.
Het verwijderen van de nieuwe eigenschap Id in mijn ApplicationUser-klasse loste deze fout op.
Antwoord 7, autoriteit 2%
Ik kwam dit probleem tegen en het was een conflict met de objectnaam. De IdentityConfig.cs gebruikte ApplicationUser, maar het gebruikte de automatisch gegenereerde IdentityModels.ApplicationUserin plaats van de DataAccess.ApplicationUservan mijn eigen context. Het was volkomen logisch toen ik het eenmaal vond. Dus ik heb de automatisch gegenereerde IdentityModels.cs uit de basis WebAPI-sjabloon verwijderd – die ik toch niet meer gebruik – en vervolgens heb ik de gebruiksverklaring in IdentityConfig.cs toegevoegd aan mijn eigen DataAccess-naamruimte en voila, juiste toewijzing. Als je vergeet dat de sjabloon veel van dit voor je heeft gemaakt, loop je tegen het probleem aan:
public class ApplicationUserManager : UserManager<ApplicationUser> // the name conflict
{
public ApplicationUserManager(IUserStore<ApplicationUser> store)
: base(store)
{
}
Antwoord 8
Mijn probleem was dat ik een nieuwe DbContext had gemaakt, maar deze erfde niet van IdentityDbContext.
Een gemakkelijke oplossing…
public partial class GoldfishDbContext : IdentityDbContext<ApplicationUser>
{
....
}
Antwoord 9
Ik weet zeker niet waarom dit gebeurt, mijn oplossing werkt prima, ik heb alles getest voordat ik ga slapen. Na 12 uur controleerde ik het opnieuw en voer het uit en dit was precies dezelfde fout. Ik heb bijna alle oplossingen hier in SO geprobeerd, maar geen enkele werkt.
Ik implementeer hier een databasebenadering. Toen was er ineens dit
Standaardverbinding
op mijn web.config die Visual Studio heeft gegenereerd toen ik de oplossing voor het eerst maakte. Dus ik heb het gebruikt in plaats van de verbindingsreeks die is gegenereerd door mijn EDMX-bestand en plotseling werkt het!
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("DefaultConnection", throwIfV1Schema: false)
{
}
public static ApplicationDbContext Create()
{
return new ApplicationDbContext();
}
}
Dit was mijn verbindingsreeks die werkt:
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\aspnet-System.WEB-20180718085411.mdf;Initial Catalog=aspnet-System.WEB-20180718085411;Integrated Security=True" providerName="System.Data.SqlClient" />
Oorspronkelijk gebruik ik dit dat werd gegenereerd door mijn EDMX-bestand, maar plotseling werkt de website niet, hoewel het eerder werkt. Ik veranderde niets en alle code was in TFS, dus ik ben er 100% zeker van dat het werkt en ik heb een volledig herstel gedaan en de nieuwste versie ontvangen:
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\aspnet-System.WEB-20180718085411.mdf;Initial Catalog=aspnet-System.WEB-20180718085411;Integrated Security=True" providerName="System.Data.SqlClient" />
Antwoord 10
Dit gebeurde met mij omdat ik probeerde applicatieSermanager en enkele andere gerelateerde afhankelijkheden te winnen met behulp van mijn afhankelijkheid injectiecontainer. In sommige gevallen zou de container opgelost applicationdbcontext in andere gevallen de ingebouwde injector in OWIN het oplost.
De gemakkelijkste manier om ervoor te zorgen dat dit niet gebeurt, is door niet te proberen om Auth-dingen te verbinden met uw DI-container naar keuze, tenzij u echt weet wat u met DI doet…laat Owin het anders gewoon oplossen met behulp van de ingebouwde injector.
Met andere woorden, verwijder iets als:
builder.RegisterType<ApplicationUserManager>().InstancePerRequest();
En laat Owin het gewoon oplossen zoals het is ingebouwd:
public ApplicationUserManager UserManager
{
get
{
return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
}
private set
{
_userManager = value;
}
}