52

I'm migrating from Identity 1.0.0 to Identity 2.0.1 following this article

and the migrations code generated is nothing about the new IdentityUser. It doesn't add the new columns.

So I made a new project and tried again but the migrations codes is empty.

To fix that problem, I did the edits directly in SQL Server and imported my database again in my solution.

Now my AspNetUser is exactly the same as my IdentityUser as you can see

IdentityUser

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 

and when I try to register a user I have the following exception

The entity type ApplicationUser is not part of the model for the current context

at this line

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

My startup.Auth.cs

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

And in my AccountController I declare my UserManager like this

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

I haven't changed anything except the new properties in the AspNetUser class and it used to work well before the migration.

There's a similar issue on CodePlex marked as fixed but they don't give the solution

Does anyone know how to fix this?

EDIT

To be sure I didn't do any mistakes when I edited my SQL database. I created another project and generated an Identity database and I changed the connection string for that database and I still have the same error.

SOLUTION

When I have edited my database I haven't noticed that in Identity 2.0.0 they changed the User_Id for UserId in AspUserClaims table. After doing that I had the same error but then I did what tschmit007 said about adding the ApplicationDbContext to the UserStore constructor and now it works.

UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()));
Nikolay Kostov
  • 16,433
  • 23
  • 85
  • 123
Marc
  • 16,170
  • 20
  • 76
  • 119

10 Answers10

72

I was having this same problem. I’m doing database first development with an EDMX file.
If you are using the connection string generated when adding the EDMX file in :base(“EDMXConnString”) you will most likely have this problem.

I fixed this by creating a standard connection string that pointed to the database where the ASP.NET Identity tables are.

<add name="MyConnString" connectionString="Data Source=server; Initial Catalog=db_name; User ID=user_id; Password=password; Connect Timeout=60;" providerName="System.Data.SqlClient" />

And then used that connection string in :base, and it worked!

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("MyConnString")
    {
    }
}
OL.
  • 201
  • 3
  • 13
James
  • 1,440
  • 14
  • 12
  • 8
    This also fixed the problem for me (in a database first development situation). – SeraM Feb 10 '15 at 23:27
  • Connection String correction works, but if anyone has problem with "invalid column name Hometown" error just delete hometown field from IdentityModels.cs and it's usage in AccountController, I used older script for genereting tables on db and I guees they don't have hometown field therefore I was gettin this error... – solujic Feb 09 '18 at 18:44
  • It's already 2019 and 2020 is coming. It is still working. Nice. – Jansen Sep 25 '19 at 13:54
  • Works like a charm, I do hate having to create an additional connection string. But nonetheless it works! – Brendan Sluke Oct 13 '19 at 00:32
  • @James Does this mean that we need two connection string in the web-config file? One for the Identity Model and One for the EDMX model? – Fahad S. Ali Aug 03 '20 at 02:08
43

for me it seems to miss a context instanciation:

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

should be

UserManagerFactory = () => new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()));
tschmit007
  • 7,559
  • 2
  • 35
  • 43
  • At first I tried with `new MyDbContext` as a parameter for the UserStore constructor, im gonna try with `ApplicationUserDbContext` – Marc May 27 '14 at 16:22
  • @Marc sorry, it is `ApplicationDbContext`in your case – tschmit007 May 27 '14 at 16:24
  • The model backing the 'ApplicationDbContext' context has changed since the database was created. I will try to do a migration to see what has changed – Marc May 27 '14 at 16:46
  • The migrations code drops everything and creates my database from scratch. Is it normal? Why do I have 2 contexts. ApplicationDbContext and my myDbContext. I'm confused – Marc May 27 '14 at 16:54
  • Also I noticed that the migrations code creates the old version of my AspNetUser – Marc May 27 '14 at 16:56
  • Do you have an idea why? – Marc May 27 '14 at 19:36
  • It works... if I follow your answer with the new database. the only difference with my old one is that they changed User_Id for UserId in the AspUserClaims. Thats why your answer wasn't working at first I guess. – Marc May 28 '14 at 13:37
  • I completely forgot to add thee context in on the UserStore as well /facepalm – Ortund Aug 17 '17 at 12:39
9

My problem was I tried to use generated ADO.NET connection string for both generated and authentication context ApplicationDbContext. I fixed it by using a separate connection string for authentication. Also pay attention to the provider - for authentication context it has to be System.Data.SqlClient:

<add name="DefaultConnection" connectionString="Server=qadb.myserver.com;Database=mydb;User Id=myuser;Password=mypass;" providerName="System.Data.SqlClient" />
shturm
  • 857
  • 7
  • 18
4

If you are using code first, check your connection string to ensure providerName is 'SqlClient' as in providerName="System.Data.SqlClient

If you are using database first, check your connection string to ensure providerName is 'EntityClient' as in providerName="System.Data.EntityClient

snnpro
  • 193
  • 2
2

Same problem to me, it solved by this code:

public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false)
{
    Database.Connection.ConnectionString = @"data source=...;initial catalog=...;user id=...;password=...;multipleactiveresultsets=True;application name=EntityFramework";
}
Shayki Abramczyk
  • 36,824
  • 16
  • 89
  • 114
Nabeel Ali
  • 21
  • 2
1

I also received this error message, but the cause and solution were different. In my case, I had introduced a new Id property of type Guid in my ApplicationUser class. Perfectly valid C# syntax, but it apparently created massive confusion for the Identity or EntityFramework core that relies on reflection to find stuff.

Removing the new Id property in my ApplicationUser class resolved this error.

dthorpe
  • 35,318
  • 5
  • 75
  • 119
0

I ran into this issue and it was an object name conflict. The IdentityConfig.cs was using ApplicationUser, but it was using the auto-generated IdentityModels.ApplicationUser instead of my own context's DataAccess.ApplicationUser. Made perfect sense once I found it. So, I deleted the auto-generated IdentityModels.cs from the base WebAPI template - not using that anymore anyway - then I added the using statement in IdentityConfig.cs to my own DataAccess namespace and voila, proper mapping. If you forget the template built a lot of this for you, you'll run into the issue:

public class ApplicationUserManager : UserManager<ApplicationUser> // the name conflict
{
    public ApplicationUserManager(IUserStore<ApplicationUser> store)
        : base(store)
    {
    }
Auri Rahimzadeh
  • 2,133
  • 15
  • 21
  • hi, after much searching I found this I have a similar problem, in which 2 files/classes did you find the section applicationUser, and which one did you delete – Transformer Mar 03 '17 at 05:35
0

My issue was that I had created a new DbContext, but it wasn't inheriting from IdentityDbContext.

An easy fix...

public partial class GoldfishDbContext : IdentityDbContext<ApplicationUser>
{
 ....
}
James Joyce
  • 1,694
  • 18
  • 20
0

I am sure not why this happens, my solution works perfectly fine, tested everything before I sleep. After 12 hours, I checked it again and run and this was exactly the same error. I tried almost all solutions here in SO but none of them works.

I am implementing a database approach here. Then suddenly there was this

DefaultConnection

on my web.config that Visual Studio generated when I first created the solution. So I've used it instead of the connection string that was generated by my EDMX file and suddenly it works!

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("DefaultConnection", throwIfV1Schema: false)
    {
    }

    public static ApplicationDbContext Create()
    {
        return new ApplicationDbContext();
    }   
}

This was my connection string that works:

<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" />

Originally I am using this that was generated by my EDMX file but suddenly the website doesn't work although it works before. I didn't change anything and all code was in TFS, so I am 100% sure it works and I did a full restore and get the latest version:

<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" />
Willy David Jr
  • 8,604
  • 6
  • 46
  • 57
-1

This happened to me because I was trying to wire up ApplicationUserManager and some other related dependencies using my dependency injection container. In some cases, the container resolved ApplicationDbContext in other cases the built-in injector in Owin would resolve it.

The easiest way to make sure this doesn't happen is to not try to wire up any of the Auth stuff using your DI container of choice unless you really know what youre doing with DI...otherwise just let Owin resolve it using the built in injector.

In other words, remove anything like:

 builder.RegisterType<ApplicationUserManager>().InstancePerRequest();

And just let Owin resolve it the way it was built in:

 public ApplicationUserManager UserManager
    {
        get
        {
            return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
        }
        private set
        {
            _userManager = value;
        }
    }
parliament
  • 21,544
  • 38
  • 148
  • 238