UserManager.CreateAsync 不生成 Id

Question

I just upgraded my MVC 5 application (was previously MVC 3 with SimpleMembership ) to ASP.NET Identity 2.0 and I can work with existing users, but when I execute the following to create a new user:

var user = new ApplicationUser();
//user.Id = db.Users.Max(u => u.Id) + 1;    //does not help
user.UserName = model.UserName;
user.Email = model.EMailAddress;
var result = await UserManager.CreateAsync(user, model.Password);

I get the following:

System.Data.Entity.Core.UpdateException: An error occurred while updating the entries. See the inner exception for details. ---> System.Data.SqlClient.SqlException: Cannot insert the value NULL into column 'Id', table 'MyDB.dbo.AspNetUsers'; column does not allow nulls. INSERT fails. The statement has been terminated.

Does anyone have an idea why this is happening?

This is my UserManager :

var manager = new ApplicationUserManager(new ApplicationUserStore(context.Get<MyDbContext>()));

manager.UserValidator = new UserValidator<ApplicationUser, int>(manager)
{
    AllowOnlyAlphanumericUserNames = false,
    RequireUniqueEmail = true
};

manager.PasswordValidator = new PasswordValidator
{
    RequiredLength = 6,
    RequireNonLetterOrDigit = false,
    RequireDigit = false,
    RequireLowercase = false,
    RequireUppercase = false,
};

manager.EmailService = new EmailService();

var dataProtectionProvider = options.DataProtectionProvider;
if (dataProtectionProvider != null)
{
    manager.UserTokenProvider = new DataProtectorTokenProvider<ApplicationUser, int>(dataProtectionProvider.Create("ASP.NET Identity"));
}

I use int keys for the users and roles, but I had the default string -keys before and there the Id was also not filled and I got a similar error.

Answer 1

I found the problem:
Because I changed the key from string to int the following migration was created:

AlterColumn("dbo.AspNetUsers", "Id", c => c.Int(nullable: false, identity: true));

There it correctly generated identity: true , BUT MSSQL can't convert an existing column to an identity column => the column became a "normal INT column".
Identity must then asume that the column is an identity column and inserts null as the key and expects the DB to generate the id => exception.

The solution was to revert back to my SimpleMembership DB from an old backup and directly convert it to ASP.NET Identity using the int -key when creating the AspNetUsers -table.

PS: But I still don't know why I had similar problems with string -keys, but I like the int -keys better anyhow...

Answer 2

Just ran into this issue, and it wasn't immediately clear to me what to do to solve it while keeping the migrations, so I'm adding this answer as a further clarification to what @ChrFin mentioned in his comment.

If you switched to Int Id from Guid through a migration, this is what you have to modify in the given migration to create tables on which UserManager.Create() won't fail:

//AlterColumn("dbo.AspNetRoles", "Id", c => c.Int(nullable: false, identity: true));
DropColumn("dbo.AspNetRoles", "Id");
AddColumn("dbo.AspNetRoles", "Id", c => c.Int(nullable: false, identity: true));

// ...

//AlterColumn("dbo.AspNetUsers", "Id", c => c.Int(nullable: false, identity: true));
DropColumn("dbo.AspNetUsers", "Id");
AddColumn("dbo.AspNetUsers", "Id", c => c.Int(nullable: false, identity: true));

Additional information on the correction needed, to answer a comment:

These modifications go in the Up() method of the auto-generated migration file. Basically, if you have this issue, you should be able to find the commented line AlterColumn("dbo.AspNetRoles", "Id", c => c.Int(nullable: false, identity: true)); (or the equivalent thereof), if you search for it in your solution.

The migration file's Up() method will contain other lines/operations too, but they can be left as is, and only the above two needs to be overridden.

I'm actually not been working with ASP.NET MVC for a while (switched to Core), but from what I can recall, the migrations can be executed with the Updade-Database command in the Package Manager command line.

But , of course, first you have to roll back the last migration (the unmodified one, that caused the problem). From what I can recall, rolling back to a previous migration is done with the Update-Database -TargetMigration:"migration_name" command, where migration_name is the name of the preceding, still good migration.

Answer 3

I had this same problem after switching to int Id from Guid (random string) but I was able to solve it in a different way. I was able to use the SQL Server Object Explorer (SSOE). I opened the SSOE, found my database and expanded the tables, and right-clicked dbo.AspNetUsers >View Designer. I saw that Id was an int, which I thought was correct but actually it should be uniqueIdentifier. I tried to change the data type to uniqueIdentifier but could not. When I clicked Update it was unsuccessful, it gave me an error message about it being referenced as a foreign key in other tables. It listed 3 tables I think, and if you follow the trail it leads to the table dbo.AspNetUserClaims . aspNetUserClaims designer

If you change the UserId field here to uniqueIdentifier it will cascade and change the data type in the other tables as well, all the way back to AspNetUsers.