I am working on CodeFirst and have auto-generated the DbContext and Entities models for the first time.
It successfully generated Entity Models:
But for awhile, the Database has had some new tables, and I have had to generate new C# Entity models. Currently, there is no way allow me to automatically generate a new Entity class for the existing DbContext.
Would you please advise me on it?
You have three options (to my knowledge):
Delete DbContext and existing models and regenerate from scratch. If you haven't made any changes to the default context or entities this is an easy approach.
Generate a new model and copy and paste the DbSets and model configurations into your existing DbContext. Then you can just delete the newly generated context.
EntityFramework Migrations - Once you have the database created you can make future updates to your code-first model and then apply them to your database rather than the other way around.
Related
I am building a .NET Core 6 web app using individual authentication.
The default identity tables are stored on the same DB as other custom tables. Some of the tables and columns will be updated from time to time in a DB-first manner.
I can manually add entity Properties in the OnModelCreating method of ApplicationDbContext, but that is quite tedious, there isn't a great way I know of to keep track of the diff between the db and the entites, and I risk mismatching types.
I can quickly scaffold individual tables into my ApplicationDbContext. I can scaffold new entities or use the force flag to overwrite existing entities, but as far as I can tell, it rewrites the entire file.
Assuming I have an AspNetUser class that inherits from IdentityUser, is there a way to ignore the properties defined in IdentityUser when scaffolding?
Migrations work nicely because they keep track of just the changes since the last migration, but any changes to the DB are required to be made in the DB first for this project.
Using EF Core 6 is there a way to update extended entities in a cleaner way?
Is it best to create new related tables to contain any data specific to a user (such as FirstName, LastName) and avoid generating all new definitions for default identity properties?
Is it best-practice to just ignore the IdentityUser class and adopt the generated AspNetUser class with properties identical to those in IdentityUser and any additional properties when scaffolding to update entites with DB changes?
Thanks for the guidance!
Is it possible to work with Entity Framework without a database, using the generation of data and relations from code, by initializing and populating the model? For this you need to write a custom DbContext and DbSet?
Trying to grasp the big picture here. This is a Web Forms project using Identity + EF for user management. The default project contains IdentityModels file which suggests that I should add custom properties to ApplicationUser class and then use migrations to update my database. I did that and the database was generated/updated. So far so good.
Now I add a new EDMX to my project and import all my DB tables into it. This obviously brings in Identity tables into the diagram as well, which is good because I'll be adding my business domain tables and linking them to Identity tables through the model and then use migrations to update my database. Here are the questions and problems I face:
Am I using Code-First or Model-First, or a mix of both (Does such a mix work)?
Do I have more than one model in my project, namely the default Models file and the one generated by EDMX?
If I have two models, which of the model classes correspond to AspnetUsers table; the default ApplicationUser class or the AspNetUser class generated by the EDMX? I mean which of these classes will be used by migrations to update my table's structure?
Adding new properties to my ApplicationUser class doesn't seem to have any effect when I run Add-Migration and Update-database commands. It generates empty Up() and Down() functions.
Adding a new property to an EDMX entity and then trying to send it to the database through migrations throws error saying that the new property doesn't have a mapping column. Now that's obvious I know, but then how does Model-First approach send changes to the DB?
I know these are more than one questions, but they are tightly related and anyone trying to get a start will most probably face all of them, so I've gathered them in one place for future readers.
In my understanding using both EF Code-First and Model-First can add a burden of keeping them in sync. You may want to check the following sample project which uses only DbFirst approach:
https://github.com/kriasoft/AspNet-Server-Template
OK. After working with the project for a few days, I have figured out a few things that might be helpful for future readers:
As #Konstantin said, as a general rule, you should not use both code-first and model-first approaches in the same project. Personally I prefer database-first over both of them, i.e. create a database design and then import it into my EDMX model. I can then make changes to my DB design later and use "Update Model from Database..." command to refresh my model.
AFAIK, migrations cannot currently be used with EDMX models. These only work with code-first approach.
ASP.NET Identity will automatically create all required tables in your database when your website runs for the first time. You simply need to correct the connection string in your web.config file.
You should generally avoid bringing in Identity tables into your EDMX, but if you really need to do that, do not make changes to these entities through EDMX. Simply use ApplicationUser class in IdentityModels file to add custom properties to your user class.
I'm building an application that will be exposed to the public. So the database will be filled with data. I'm not sure how to extend the model afterwards. Locally after any changes of the model the database get's recreated. How can add properties to the existing model, without recreate the entire database ?
Take a look at EntityFramework CodeFirst Migration, for modifying your schema.
MSDN Link for Migrations
I'm testing with EF 4.3 (beta)
I have some new classes which should generate db tables and columns.
From a old project i have some old tables in my schema, which i want to access via EF.
All Classes are declared. For accessing the old table, there is a poco which is mapped.
The db migrations tries to create that old table, too.
How can it set that this class/table is not part of the migration, but part of the ef model?
xxx.OnModelCreating()
{
modelBuilder.Ignore<myOldTableClass>();
}
removes the entire class from model. finally i can't use it for access via dbContext.
i like to use automatic migrations.
i try to avoid to migrate old db tables completely to EF classes. (Yes, i know there are generators for that)
there are 120 tables, which are still used by an old applications.
some new tables which are only used with EF (new app).
there are 3 common used tables.
those should not created but accessed via ef.
With EF 4.3.1 released there is built in support for this scenario. When adding classes that are mapped to existing tables in the database, use the -IgnoreChanges switch to Add-Migration.
This will generate an empty migration, with an updated meta-data signature that contains the newly added classes.
Usually this is done when starting using EF Migrations, hence the "InitialMigration" name:
Add-Migration InitialMigration –IgnoreChanges
The correct workflow in this case is creating first migration prior to adding changes (new classes), than adding new classes and after that creating new migration where you will have only new tables.
If you didn't use migrations so far the framework will generate migrations for all tables you have in the project because it believes you are creating initial migration. Once you have migration generated you can modify its source file and remove CreateTable code for old classes from Up method. The problem is you will probably have to do this in any subsequent migration.
Edit: I wrote a walkthrough for adding migrations to existing project with EF 4.3.1