I had an ASP Net web forms application with database using Database First Approach. I then merged Aspnet Identity Tables into my existing db. Then i used Entity Framework Reverse Enigneer extension to convert to Code First.
I got the Code First POCO classes & mappings for My existing db. However for Aspnet identity i got only one file i.e. IdentityModels.cs. NO Code First Model classes.... IS IT RIGHT ? Should i have got those POCO classes for AspNet identity tables as well ??
I also want to refer to User Id of the AspNetUsers table into my db tables...Since there are no POCO classes... How to refer to them ???
Further, There are now two contexts.. a) ApplicationDbContext derived from IdentityDbContext. b) MydbContext.... How to unify them if possible ???
Things seem scattered.
Not much documentation by Microsoft or otherwise...or the framework has become obsolete ????
Any help is appreciated.
It seems WebForms have been ditched starting VS 2017 & .NET Core.
Its time to move on to Razor Pages or MVC.
Related
A while ago I asked this question about using EF with ASP.Net core, and this is working great. Now that I want to add ASP.Net Identity, I'm wondering if the best approach is to add identity logic to the separate project with regular / non-core EF, or into the main core project with EF core, or something else. I see a lot of pages that discuss EF core, but I would prefer to use the same context everywhere, and I would prefer to use regular EF as I am currently doing. I'm looking for what would be a clean / best practices approach here, I have been using regular EF since to my knowledge EF core 1.0 doesn't support stored procs, and I prefer to continue to use a database first approach anyway. Appreciate any help that gets me out of the quicksand.
NOTE: My 'User' table (called something else) has some existing profile data in it; I intend to use this as my Identity User table.
Have you considered having an explicit Identity service that can issue tokens based on your existing identity database?
IdentityServer4 is an OpenId Connect provider. It supports EF so that you can use your existing user data to perform authentication.
The push now is towards .NET Core and it would be a good step in that direction to have a separate project dedicated to handling identity that uses IdentityServer4 and EF Core.
ASP.Net Identity Framework is designed for Code-first, and will normally try to generate its tables for you. I'm not sure if it is able to work Database-first, but I think you could get it working as follows:
Create a separate, temporary, project/solution with Identity / Individual User Account.
Insert the data structure from this temporary database into your main database, merging AspNetUsers with your User table.
Delete the temporary project/solution and database.
Update the models in your EF6 project. This should bring in the new tables.
Add Identity Framework to your ASP.Net Core project, referencing the database context from your EF6 project.
I haven't tried this, but having worked with Identity Framework quite a bit I can't see a reason why it wouldn't work.
Further reading:
Database first Identity: Using Asp.Net Identity DataBase first approach
Custom table name for Users table: How can I change the table names when using Visual Studio 2013 ASP.NET Identity?
I have two solutions in c#:
One solution is identity server with asp.net core identity integration, which on first run creates identity user tables.
The second solution I have API, and project Data Layer, where I will implement custom tables.
How do I approach this architecture design, to make sure all migrations will know each other and there wont be data issues. In case I have to create additional table for AspNet_Users and link it with other table, I only have option to put it in Identity solution, but what if there are multiple links? How can I achieve proper architecture here?
I've currently got an ASP.NET MVC project, with three C# Class Libraries for Data Access, Settings and an Entity Framework Code First project.
I am currently trying to add a SQL Database Project to my solution so that I can manage my database more closely and add extra items that entity framework doesn't deal with.
I have searched around for integration options and can't find anything more helpful than going the DB first route and updating an edmx model from that.
How would I go about integrating my code first entity framework project with my SQL database project in a way that lets me edit the tables with code first and manage stored procedures and the rest with the database project.
If this is possible, is there any particular way to get these to deploy without conflicting?
Thanks!
My title is a bit complex, but I will break down really simply what I am doing here.
I have an existing database with about 20 tables. I have a project that my partner has decided that we should use the old Simple Membership over Identity. This is no longer an option on the table, we have finalized that decision. WE will be creating the project in Web Forms using Visual Studio 2012 because that is what we have licenses for.
Step 1) I started a new project in VS 2012 using Web Forms and I pointed the Default Connection String at my current database and registered a few users. This created the tables I needed for membership in my SQL Server 2012 database.
Step 2) I did some relational mapping in my database connecting existing tables to the new membership UserID's where needed so that my existing tables are now related to the membership stuff.
Step 3) Here is where I am a bit lost because normally I have used SqlDataSources with Web Forms in the past. I have some experience with MVC so I would like to do things differently in this web forms project and start from Database First and import my database tables into a Data Access Layer, I'm thinking of using a Class Library for this.
MY QUESTION: When importing my EDMX for database first. Should I
A) Bring in all of the tables (Existing Tables + New Membership Tables)
B) Just bring in the Tables that are NOT part of Membership?
C) Bring in my Existing Tables and only the User and Membership table? or
D) Do you have any other idea?
My reasoning for this question is that I know that I can access the Membership stuff in the Web Forms Project but will it possibly be needed in the Class Library since my application will eventually be very User centric. Lots of tracking of user time and logins, assigning tasks and projects, permissions to that user etc.. I was leaning toward (A)
I know this is a very complex question or maybe I should say it may have many answers all due to things that I may not know yet or I have not explained fully. But I'm looking for some direction as I have never used a Class Library or Database first in this way or in a Web Forms Application.
Snapshot of Database:
You really don't need to include the Membership tables in the EF model. As you pointed out, the Membership class will handle it as long as you have it properly configured in the Web.Config file.
You should import only those tables that are related to your application.
You would only import the membership tables only if you are building a custom membership provider, which is old news by now.
At least, I personally don't do it. This also helps to keep the EF model with just what I need.
Hope it helps.
How can I link a table created with the Code-First approach to the default Users table of ASP.NET? I am working with Entity Framework 4.3.1 and MVC3 in C#.
The project I am working on is meant for an organisation that organizes tournaments. When they create a tournament, a new user has to be created linked to that tournament so that when this user logs in, he can only work with that particular tournament.
Any idea how to make this relation with Code-First?
Thanks in advance,
Bart
I would deploy the tables to your database for reference, then copy them into models. Just make sure to get all the relationships correct for the FK, etc. You should then be able to have EF deploy the database and use the built-in membership tables.
If you ever upgrade to MVC4 with SimpleMembership, check out this example: http://blog.spontaneouspublicity.com/including-asp-net-simple-membership-tables-as-part-of-your-entity-framework-model