I’m trying my first asp.net mvc 5 project, which more or less forces you to use the new asp.net identity framework for membership. It’s in the using Microsoft.AspNet.Identity namespace.
While a vast improvement over the original asp.net membership – I do not see any massive benefit over the MVC 4 Simple Membership system. Here are 5 things you need to know about the asp.net identity system before you upgrade
- The ID column is stored as a guid, and not an int – One of my favorite things about the simple membership system was being able to use int columns for ID – no more of that
- In the default project, all of the membership tables will be stored in Local DB, even if you change the connection string in the web.config
- MVC introduces a peculiar (to me at least) way of creating the Database tables for membership in the LocalDB – in the IdentityModel.cs file in the Models folder, you will see the following bit of code
public class ApplicationDbContext : IdentityDbContextWithCustomUser
{
}this will create the following tables in the Local DB
- ASPNetUsers
- ASPNeRoles
- ASPNeTokens
- ASPNetUserClaims
- ASPNetUserLogins
- ASPNetUserManagements
- ASPNetUserRoles
- ASPNetUserSecrets
if you are running a separate database you will find it quite confusing to get the membership and the other data in the same context (the error message are rather opaque. To fix the matter, add in the following code in your regular data context class and comment out the ApplicationDbContext : IdentityDbContextWithCustomUser in IdentityModel.cs
public DbSet ApplicationUsers { get; set; }
public DbSet Roles { get; set; }
public DbSet Tokens { get; set; }
public DbSet UserClaims { get; set; }
public DbSet UserLogins { get; set; }
public DbSet UserManagements { get; set; }
public DbSet UserRoles { get; set; }
public DbSet UserSecrets { get; set; }and everything will both be in the same database and the same data context.
- The quick and easy way of getting the User ID (comparable to WebSecurity.CurrentUserID is User.Identity.GetUserID() – that will return the guid of the user.
- It is pleasantly integrated with entity framework code first, and will probably be a positive feature over time.
|
|
Written By Steve French |
Hi there,
I too am just moving from MVC 4 to MVC 5 and learing as much as I can right now about ASP.NET Identity.
It seems about a week or two ago (March 10, 2014) they just released a version 2.0.0 of Identity which lets you now configure the type of primary key you’d like to use for your Users and Roles. So, seems you can go back to having an Int if you’d like!
I also found initially tables getting created in a LocalDB, not sure what I did other than updating to 2.0.0, but by changing the connection string for this in Web.Config I was able to have it build these tables in my Sql Server where I wanted it all along. Just a word of caution, if you upgrade an existing 1.0.0 to 2.0.0, there are some extra steps you need to take using EF Migrations to get things working again. They have a blog post on the blogs.msdn.com site with more details about everything I’ve just posted.
Thanks!
Hi,
I’m pulling my hair out with this issue (#2 and #3) as well. I’ve copied your code segment to my ApplicationDbContext class, but User.Identity is still pulling data out of its own DB somehow.
Do you know what I might be missing?
Thanks,
Angie
BTW, my project is a Web API project out of VS2013 template.