Develop Reference

Migrate EF6 database-first from SQL Server to PostgreSQL

I am looking for easy way to reuse edmx file created with EF6 over SQL Server to PostgreSQL
I have used database-first with EF6 on SQL Server and everything worked fine.
We are going to use PostgreSQL.
I have already migrated the database to PostgreSQL, and installed EntityFramework6.Npgsql, and I wanted use database-first approach again.
I tried to update from database but it looks that I have to fix all the edmx file. The original entity model is quite complex, with abstract class, complex types and enum types.
The new edmx file lost inheritance and complex types.
Do you know an easy way to do it?

I don't know if you can get the EDMX file to work with PostgreSQL, but you might be able to use scaffolding and get a db first approach. Something like:
dotnet ef dbcontext scaffold
This would allow you to make changes in the database and have them reflected in code. I'm no PostgreSql expert but this article sure makes it look like it's possible.
If you want a more graphical approach then you may want to consider switching to code first and using the class designer in visual studio.

Why .edmx auto generation no longer in .net core

I just noticed new Entity Framework Core does not provide .edmx generation any more. But I was loving this because it helps me to focus on application logic, not always create class and do migration things to update database. Now my question is- Does Microsoft have any future plan to add .edmx on Entity Framework Core? Or its permanently gone from .Entity Framework Core? I searched over internet but didn’t found any good answer for that.

I have not found any justification of this decision though I suppose this discussion can be found at least in some podcasts with EF team members interviews. In my opinion, this feature simply didn't deserve enough attention from developers and it didn't worth it to continue its support. Most people, as far as I'm concerned, moved towards code-first approach. You can concentrate on application logic even better with it, not creating any data objects in advance, but evolving your data structure together with business logic objects. That's what I can say based on my experience. Try it and maybe you will love it the same!

Edmx is not there in Entity Framework Core. It only supports a code-first approach. It produces entity class files instead of an edmx file. You can use dotnet ef dbcontext scaffold, it scaffolds a DbContext and entity types for a database.
You can refer the document to start with the already existing database.
https://learn.microsoft.com/en-us/ef/core/get-started/aspnetcore/existing-db

If you are on heavy load complex database and developing application using this database continuously then there is no easier way than just press refresh button in .edmx file and get your new models ready to use. I think .edmx idea still deserves development for future. Lot of solution already made with it and continuing with .edmx

ASP.NET C# How can I include my models in my code?

I'm trying to set up Entity Framework 6 in my project to facilitate the programming. However, I'm facing some kind of weird trouble.
I tried to follow this tutorial but with my own DB. http://www.aspsnippets.com/Articles/Simple-Entity-Framework-Tutorial-in-ASPNet-Web-Forms-with-example.aspx
As I tried to create an ADO Entity Data Model, everything worked fine and I got my model done. I'm able to see it in the model explorer. However, I'm not getting anything in my "Models" folder, and I cannot add a reference to my model in my using statements.
Which makes me not able to create the kind of functions as described in the tutorial.
Has anyone a clue about how to solve this?

Using EF with Database First or EDMX First will hold you back while learning Entity Framework. The best way to learn it is from the ground up, using Code First. DB or EDMX First only really come into play when you're reverse engineering old databases, and even in these cases, you'd be better to rewrite the database in Code First and phase out the old one.
There is a really good tutorial I've found here: Entity Framework Code First End to End. It teaches best practices, as well as going into detail about how and why it all works. It's one of the best ways you can spend 75 minutes when learning Entity Framework.
Start off small, and build outwards. In EF7, they are phasing out the EDMX, so even when working with Database First, you'll need to know everything about Code First in order to make it all work properly. The scaffolded code generated by Database First is really badly written, and needs refactoring as soon as it lands. You'll be refactoring and adapting the code anyway, so Code First is,in most cases, more straightforward.

Database codefirst entity framework

I'm working on an ASP.NET project. I migrated my database named "youbay" with
reverse engineering. It worked. My database contains tables (picture, user, product...) but when I try to change something on the code and then update my database it with code first other tables are then created named youbay.picture,youbay.user...

What do you concretely mean with RE? Creating ASP.NET Models by guessing the mapped .NET types of the table scheme? Maybe your db-structures are a bit different from the ones EF would genereate itself, so that EF will see a conflict. Or EF keep track of the changes itself, so he isn't touching the tables because he won't recognize that he created them.
Whatever happened, it seems like your way of migrating was not very clean. You should tell EF use an existing database like explained here. This will prevent conflicts and also save work/time, because EF will automatically generate your models based of the database-scheme. So no RE is needed.

There is already an object named 'TableName' in the database. - a different solution

This is not really a question (yet!) but rather sharing something that happened to me last night and the solution was completely different from those found on stackoverflow or google.
After adding some new functionality to an existing application which resulted on a couple of changes on the model I deployed the application to our development environment without an issue. However, when I deployed it to our production environment I started getting this "There is already an object named 'TableName' in the database." error.
Clearly, Entity Framework was trying to (re)create my model from scratch instead of updating it. After trying several solutions including the Global.asax SetInitializer(null), resetting migrations, etc. nothing worked and would only lead to other errors.
At some point I just rolled all of my attempts to fix changes back and started from scratch looking for a solution.
The solution was actually to go into the very first Migrations file (typically called init or Initial) and comment out the code that was trying to create the tables.
Afterwards, I could see that there was another migration trying to dropfield also generating an equally ugly error (something along the lines of "Unable to remove field 'FieldName' because it doesn't exist"), so I had to comment that line as well.
So basically, after commenting out a few migration lines, everything started working and the model did get upgraded to the latest version.
Now, here's the question.
Clearly, Dev and Prd were out of sync DB-wise (which is fine, to my eyes) but this ended up creating migrations that, for some reason, were not compatible with production and this is where I cannot understand how Entity Framework is not able to manage this. I mean, why was EF trying to create a table if it already existed? And why was EF trying to drop a field that was not present in the table schema?
Is this something not covered by EF? Or did something happened at some point that messed up the entire EF set up of my project?