Develop Reference

Entity Framework Core Database First

My team has inherited a database application that contains hundreds of tables. The application uses Entity Framework and takes a database first approach for development. Our current process is to pull a table or two at a time into the edmx using the Update Model From Database... tool.
We are considering making a new API with .Net Core, but as far as I can tell from the research I have done, there is no equivalent process in the Entity Framework Core tools. The closest thing I can find is to reverse engineer the entire database with Scaffold-DbContext, and then use migrations for all future database changes. We can't scaffold the entire database, because some of the tables have errors, and fixing all those errors is not a viable option for us right now.
I have found that I can supply a list of tables that I want scaffolded with the initial Scaffold-DbContext call, but I'm not sure if migrations can be used in a similar way to the Update Model From Database... tool. Can I use migrations to add tables that already exist in our database? If not, what other options should I be looking at?

C# interview questions approaches in entity Framework?

In my recent interview, my interviewer we asked about approaches in entity Framework I told them code first and table first. Is there any approaches pending.

We can use three type of entity framework approach as per project requirement.
Database First:
An existing database can be used
Code can be auto-generated.
Extensible using partial classes/ T4 templates
The developer can update the database manually
There is a very good designer, which sync with the underlining database
http://www.entityframeworktutorial.net/database-first-with-entity-framework.aspx
Code First:
There is full control of the model from the Code; no EDMX/designer
No manual intervention to DB is required
The database is used for data only
http://www.entityframeworktutorial.net/code-first/what-is-code-first.aspx
Model First:
Good support with EDMX designer
We can visually create the database model
EF generates the Code and database script
Extensible through partial classes

New MVC 5 project with Existing Db - Code first vs EDMX (entity data model)

Using MVC5, EF6... We are going to build an enterprise level app. We have an existing database. Is it best to use EF code-first and code everything by hand, which takes longer, but may be cleaner? Or should we use the EF database-first approach, using EDMX (entity data model)? Can EDMX be used for enterprise level apps, or are there performance issues, etc...? What do you suggest? Thanks!

Is it best to use EF code-first and code everything by hand, which
takes longer, but may be cleaner?
IMHO, Code First is the best solution. It may take less time if you generate the Code First classes from exiting database by doing this method. You need to also know that EDMX no longer exists in Entity Framework Core verison (formely known as Entity Framework 7). Code First may help you in the future if you plan to migrate to EF Core.
Or should we use the EF database-first approach, using EDMX (entity data model)?
In my experience I encounter a lot merge conflicts when using EDMX (from Database First or Model First). If many people have to modify the EDMX in separate branchs, they will be soon be confronted with EDMX merge conflicts. Believe me, it is sometimes difficult to fix.

How to generate Entity Framework 6.x POCO classes with mappings from an EDMX file?

I'm in the process of converting an extensive EDMX model into POCO classes. I need to go from a Database First approach (EDMX with ObjectContext) to a pure Model First approach (DbContext with no EDMX file). I need to use the latest Entity Framework stable version: 6.1.1.
I've tested some approaches:
Adding a the EF 6.x DbContext Generator code generation item by right-clicking the blank space in EDMX designer. This works fine, but it doesn't add any mappings. With this approach I have to still use the EDMX file. It's not full Code First.
Using the EF 5.x DbContext Fluent Generator for C#. This triggers an exception in design time. I'm not being able to use it. I don't know if that's because my VS Entity Framework tools are already updated to 6.x. Using the alternative TT in the comments, that suggests that it would work with EF 6.0 also doesn't help.
Using the EntityFramework Reverse POCO Generator. This is the worst because it won't consider any of my classes and navigation properties renames.
Using the Entity Framework Power Tools Beta 4. Again, it only supports generating from the database, not from the EDMX file.
My requirements:
I need the input to be the EDMX file, not the database.
I need the output to be a full Code First approach with Fluent mappings.
I need all my navigation property names defined in the EDMX to be considered because otherwise it would break a large codebase, even more then migrating from ObjectContext to DbContext will break.
What do you think would be a good option for me to go?

Well i don't think there is an easy one click solution to this.
Underneath you edmx files. You have two more files available besides the xx.Designer.cs and xx.edmx.diagram.. called xx.Context.tt and xx.tt where xx is the name of your edmx model.
These are t4 templates which genrate your dbcontext and poco objects. All your poco objects would be created underneath your xx.tt files and dbcontext underneath your xx.Context.tt files.
You now have to moves these into separate files. This is much easier if you are using EF6. and the file generated are already using DbContext and not ObjectContext.

I faced a similar case and I used Entities to DTO's generator.
Although its purpose is to generate DTO's, however, I believe it can help someone in you case.
https://entitiestodtos.codeplex.com/

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.