Develop Reference

Auto generate entity model from database to current DbContext class

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.

EF Core extending model with migrations

I have an existing database that was created with code-first approach
Now I'd want to add an another property to my model, but after running app and trying to work on that data EF Core says that
System.Data.SqlClient.SqlException: 'Invalid column name 'test'.'
That's reasonable, so I'm removing that property (test), creating migration, adding that property (test) once again, creating another migration and updating model
But now:
There is already an object named 'AspNetRoles' in the database.
How can I extend my db schema with code first without losing my data?

Adding custom columns to ASP.NET Identity

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.

How to update EF models when using DB Code first?

I have added added Entity Framework to my project and selected Code first from database when creating my models. But the problem is, i couln't find how find how to update existing models and add new models to my project when i make changes on database.

It is very straightforward. Switch on migrations, change/add you classes, create a migration and update your database. See here for example. There are plenty of other sources.

When you change your DB you can run the EF generation again but it will overwrite the existing files so you will lose any changes. If you want to maintain code outside the generated files then you can use partial classes. Or alternatively just code them by hand after the initial auto generation, it's quick once you get used to it! :)

Making changes to existing entities in Entity Framework

Suppose I have an existing database set up using Entity Framework. Is there a mechanism through which I can safely add or remove entities (or their properties) such that the database is altered automatically?
I know there's an option to "Update Model From Database". Is there an equivalent "Update Database From Model" ? Is there a way to configure Visual Studio to do this automatically?

Entity Framework 4.3 has Code First Migration support.
EF helps you with checking the differences between your code and database and then generates code for you that handles this changes. You can use the NuGet package manager console to enable migrations, add a new migration and run them against your database (or create a sql script).
This blog explains how the Migrations work and this blog shows how you can use it with an existing database

Altering the database schema isn't a straightforward operation (has a column been renamed, or is it new column? Can the old type be converted to the new type?) that you can easily infer from the model.
EF doesn't alter the tables for you - it can Drop-Create the DB for you when you change it. However, if you change the existing database by hand to suit the model, EF doesn't seem to mind. It looks like what they check for is Hash(Model) = Hash(Tables).