Last post Oct 29, 2019 12:13 AM by mgebhard
Oct 25, 2019 11:38 PM|CopBlaster|LINK
I trying to automatically create a CRUD controller based on my scaffolding but it says "cannot use table 'AspNetRoles' for entity type 'AspNetRoles' since it is being used for entity type 'identityrole' and their is no relationship between their primary
The history here is that I created a blank .Net Core Application with Individual User Accounts, Migrated my SQL Server database to include Identity Tables and populate them with data from my old SQL Membership Provider before deleting all of the old asp.net
membership tables from the database. I then used scaffolding with data annotations to generate models using the default ApplicationDbContext that inherits from the IdentityDbContext.
After scaffolding all the tables I noticed that a new ApplicationDbContext had been created in the Models folder instead of adding the scaffolding code to the once that Identities created in the Data folder, so I copied the code from the new one to the old
one and deleted the old one. I then added base.OnModelCreating(modelBuilder); to OnModelCreating to take care of a previous error having to do with Identity Tables.
Now I quite confused as to when I cannot create a scaffolding controller using the scaffolding created by Microsoft. I think it might be due to a conflict between IdentityUser of IdentityDbContext and the scaffolding created by Microsoft. I say created by
Microsoft because I got the scaffolding command from this Microsoft video. I think this might have something to do with there already being classes in
Identity that may conflict with the scaffolding created for those tables. I am thinking of deleting that scaffolding but I don't want to break references to those tables from the rest of the scaffolding.
I also find it confusing that this error refers to a primary key in a table that does not exist in the database. There is not table called identityrole in my database so I assume this must be a reference to something in entities. I am new to entities as
well as .Net Core. My previous experience involves using SQL and not entities to access my databases.
Oct 28, 2019 05:21 AM|Lewis Lu|LINK
"AspNetRoles" was included inIdentityDbContext, Since you inherit from IdentityDbContext, there is no need for you to recreate AspNet* DbSet,I suggest you remove all the built-in AspNet* DbSet and modelBuilder.Entity<AspNet*>.
Oct 28, 2019 10:01 PM|CopBlaster|LINK
"there is no need for YOU to recreate AspNet*" I never created it at all. Microsoft created it automatically when their program created the scaffolding. If those table should not be there then
why doesn't Microsoft program its script not to scaffold those if the dbcontext inherits from identity?
If I remove them then how can I write code against those tables like include username of post where the user id numbers are equal?
Oct 29, 2019 12:13 AM|mgebhard|LINK
I think the problem you are having is related to migrations and scaffolding. Migrations are great but can be confusing until you realize migrations are linear and nothing more than C# code in your project. You move forward by creating new migrations or
move back by going to a previous migration. Moving back is like undo. What you can't do is modify the table schema using T-SQL because the schema will be out-of-sync with the migrations. All schema changes must go through the code first pipeline, meaning
A migration is created when Identity is added to a project either through the Visual Studio template or by scaffolding Identity. If you run the web app and create an account it invokes the Identity migration. Again a migration is just C# code. You can
also invoke the migration manually using the standard CLI commands.
With that being said, if you want to move from the membership provider data store to the Identity data store, then just move the data. The ASP team has migration documents with T-SQL that shows how to move data from Membership to Identity. Keep in mind
the schema is different but you can certainly move the User and Role data.
Being that you have user accounts in Membership, I'm assuming you have other tables that drive your application. You'll simply follow the same pattern with these tables. First create a migration to build the table schema using Code First. Then write a
T-SQL script to move the data.
Hint: you can use migrations to seed data (move data). Meaning you can create a blank migration and add T-SQL scripts to move the data. I recommend this approach because it keeps all the DDL and DML in the project. I use it all the time.