As performance of our application is lack lustre we may try to migrate it from using Entity Framework 6.1.2 to Entity Framework Core 2.1. I cannot find a clear overview what pitfalls there will be. I do not expect too much problems arising from the need to rewrite some queries, but I am especially wondering what needs to be done about our 30+ migrations that we have for the database.
Are there examples on how to migrate Migrations from EF 6 to EF-core 2.1?
If you have EF 6 as Database-First and EF Core is Code-First. You can use reverse POCO generator. Then run Add-Migration to generate migration. Now you have to take care, You need to remove the changes from Up method. Now run Update-Database. From now onwards follow Code-first approach. you make changes in model, generate migration and run Update-Database.
Welcome yo EF Core.
Related
I know that Entity Framework migrations aren't compatible with Entity Framework Core, but I could not find a statement clarifying whether Entity Framework Core migrations are guaranteed to be compatible with all future versions of Entity Framework Core. Is there any such statement?
No. But EF -> EF Core was a rewrite, with lots of breaking changes. There is nothing like that planned for the future.
But worst-case scenario you would need to Reset All Migrations.
Is it possible to deploy / install Entity Framework Core 2.0 alongside traditional Entity Framework 6? Is it fully possible, or possible but with some hang-ups, or not possible? Is this documented somewhere? I think I've seen they said they designed it to be side-by-side, but I'm having a hard time fully confirming this. Thanks.
The official documentation says the following:
It is possible to use EF Core and EF6 in the same application. EF
Core and EF6 have the same type names that differ only by namespace,
so this may complicate code that attempts to use both EF Core and EF6
in the same code file.
If you are porting an existing application that has multiple EF
models, then you can selectively port some of them to EF Core, and
continue using EF6 for the others.
This means of course that you can install both EF6 and EF Core in the same project. I have done this in a few simple cases myself and it was working ok.
When I read posts about db-first vs. code first approaches, I get the impression that code-first is the rising star and superior to db-first so that db-fist is about to be deprecated in the future releases of Entity Framework.
I could not find an official statement from Microsoft but they seem to be endorsing code-first by things like Identity Framework etc. Would it be a mistake to start a new project using EF DB-first?
You have EF 6 for the more traditional EF and EF 7 which became EF Core.
In my opinion you are better off focusing your effort on using EF independent from either approach.
Here's a link to an article written by EF Expert Julie Lerman.
https://msdn.microsoft.com/en-us/magazine/dn890367.aspx
I'm trying to move an ASP.NET MVC 5 application to MVC 6 (ASP.NET vNext).
My existing application uses EF 6 and has some EF code first migrations. I want to port these migrations as well, because I want to be able to continue using the existing databases with the existing migrations already applied, without breaking the upgrade path.
It seems that the "new" EF Core migrations (k ef migration add ...) have quite the different format compared to the "old" EF 6 migrations:
No more Designer partial class
No more RESX file
Is there already an "official" way to upgrade these migrations? Is it supported at all? Will it be supported in the future?
There isn't really a way to do this yet. In general we strongly recommend against trying to upgrade an EF6 application to EF7 yet. EF7 is still very much pre-release.
We will have some guidance on how to do this when we get closer to RTM. We may provide some tools to help or just some guidance on how to do it.
Date: 13/April/2016
As of now it is not advisable to use EF7 in production because of following limitaions
"Because of the fundamental changes in EF7 we do not recommend attempting to move an EF6.x application to EF7 at this stage. If you want to move to EF7 to make use of new features, then make sure you are aware of the limitations of EF7 before you start. You should view the move from EF6.x to EF7 as a “port” rather than an “upgrade” ".
One area of RC1 that has a number of outstanding issues is our query pipeline. The majority of issues result in an exception when you attempt to execute a LINQ query that contains a particular pattern. There are often ways to workaround these issues by expressing the same query using different patterns, or evaluating parts of the query client-side. We try to include these workarounds in the issue, when they are available.
In RC1, there are a number of scenarios where EF7 performs slower than EF6
More Readings:https://blogs.msdn.microsoft.com/dotnet/2015/11/18/entity-framework-7-rc1-available/
In the past It's been easy to set a connection in LinqPad to a custom assembly that had EF model. Linqpad looks for a that is based on System.Data.Objects.ObjectContext which doesn't exist
How (if at all) does one make their model assembly compatible with LinqPad.?
Right now, LINQPad does not support the EF CTP's code-first: there's a feature request here.
It's almost certain that support will be added in the future - if this EF feature makes it past CTP (and maybe sooner with sufficient demand).
Edit: LINQPad now supports code-first with EF 4.1.