ReBuildAll Blog
Thoughts (mostly) on .NET development

Moving ASP.NET Identity model into another assembly   (ASP.NET)   
Visual Studio 2013 and MVC 5 has arrived (as well as the "One ASP.NET"), with ASP.NET Identity in tow. The new identity feature allows user profile information to be part of the ASP.NET Identity model. In essence, the identity data structure can be merged with whatever data your application has, creating a seamless integration of identity data and application data.

The result? You do not need to have two data models / entity models for your application (and as such, two Entity Framework DbContext's).

Microsoft also provides a description of how this can be achieved, using Entity Framework migrations.

But what if you want your data model to live in another assembly, not the default web application? Reasons for such a thing might be a shared data access layer between different applications. You could have a Web application and another service that does background processing, both of which need access to your data.

The default ASP.NET MVC 5 project will have an IdentityModel.cs file in the Models folder. This contains the expandable identity model. But it is included in your Web application.

This is a description of how you move the identity model to another DLL.

Add a class library
The first step in moving your data access logic to a central assembly is adding a new class library project to your solution. This new class library will contain the data access layer, and you will reference it from other projects that need data access.

Go into NuGet package management, and add the Microsoft ASP.NET Identity EntityFramework package to the project. This will also pull in some dependencies.

Now you are all setup to actually move the identity model here.

Move over the identity model
Next, take your Models/IdentityModel.cs file from the Web application and move it into the new class library. (Move, and do not copy it. It should not be in the Web application after this step).

Change the namespace in the file to match that of your intended data access layer.

Optionally, you might want to create a separate file for the data context class. This would be a good time to do that.

Add references and usings
Last step, go back to your Web project and add a reference for the data access library.

Open AccountController to add a new using statement for your new data access namespace.

Start working on the data access layer
And now you are done. You can now add your entity classes and add IDbSet properties to the data context class. Build your data access layer. You will have only one data context class, that has both your application data and your identity data together.

 

Comments

BALAJI LAXMANRAO BIRAJDAR Re: Moving ASP.NET Identity model into another assembly
I have a business layer between the data layer and UI layer. How can I achieve this? And ideally, we shouldn't be passing the Data Entities to the UI layer. So what is the way to move the ASP.NET Identity classes to Data Layer so that we can have a single myDbContext and allows for foreign key linking of the User tables with Application tables with Code first approach?
Charles Re: Moving ASP.NET Identity model into another assembly
What is the reason Microsoft left all of this to default as is? If a situation does not demand all the rearrangement why would anyone want to do this?
strong_wind Re: Moving ASP.NET Identity model into another assembly
I agree with Rich C. I'll try to get that code out of my AccountController.
How did you do it, Rich?
Rich C Re: Moving ASP.NET Identity model into another assembly
This worked perfectly as described. And to answer Konstantin's question, all you have to do is add a using statement on the AccountController.cs file for the namespace (e.g. DataLayer.Models) that you put your ApplicationDbContext and ApplicationUser classes in.

However, the whole reason to pull this out of the web applications (for me anyway) to eliminate the dependency of the Entity Framework reference in my web application. Since I'm doing all of my data access in my DataLayer assembly, my web application shouldn't care about entity framework. In your solution above, you make no mention of the steps to fully eliminate this from the web application so it seems like the worst of both worlds.

I'm sure I'll be able to extract all of the code out of the account controller to get this done, it just seems like it would be remiss from your tutorial not to mention this step as well. (just my two cents)
Konstantin Re: Moving ASP.NET Identity model into another assembly
What changes did you have to make in the accountcontroller.cs?