Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
I’ve used the newer Entity Framework Core on a couple projects just to give it a test drive in the v1.0 era. It felt very similar to Entity Framework 6. I figured since it seemed so similar, porting wouldn’t be too difficult. So I bit the bullet and finally decided to port an application that uses Entity Framework 6 over to Entity Framework Core 2.0. Here is a bit of an experience report on porting to Entity Framework Core.Side by Side
In theory, you should be able to run EF 6 along side EF Core. They are completely different packages, assemblies and namespaces. However in practice, that wasn’t possible in my situation.MySql.Data
This project in particular that I was porting was using MySQL. The official provider to use with EF6 is MySql.Data.Entity. This package has a dependency on the ADO.NET driver MySql.Data. EFCore has an official provider, MySql.Data.EntityFrameworkCore. It also has a dependency on MySql.Data, but a newer version. A wonderful diamond dependency. Full roadblock.Porting
I ended up removing all of the EF6 packages and references and installed the latest EF Core package and MySQL provider. Here are some of the changes that I needed to make.DbContext
My only significant change was adding a OnConfiguring override to specify which provider to use and the connection. The extension methodUseMySql
is from the MySql provider, which is being passed the connection.
SqlQuery<T>
This is no longer available and you must now use the FromSql method to perform raw SQL queries.FromSql
is available on all the DbSet<T>
in your DbContext
Namespaces
Using statements were more of a pain then anything. Really a matter of removing any using statements toSystem.Data.Entity
and replacing with relevant Microsoft.EntityFrameworkCore
Composite Key
You can no longer use data annotations to declare composite keys. This must be done through the fluent API.Lazy Loading
As of EF Core 2, lazy loading is not supported. Luckily I’ve never been a fan of lazy loading and generally find it causes more harm then good. If you are using lazy loading, there’s a package EntityFramework.LazyLoading that enables the ability with some minor changes to yourDbContext
Great article!
NOTE: “minor changes to your DbContex” should probably be “minor changes to your DbContext”
Fixed. Thanks!
I found out yesterday that many-to-many relationships need to have a joining entity that you don’t need in EF6. This changes your models and code that consumes them to be more complex. In my case, I want to be able to have “Tags” on an entity, but have to have an intermediate FooTag class. EF Core team has an open issue, but not much traction: https://github.com/aspnet/EntityFrameworkCore/issues/1368
Interesting. Thanks for the heads up!
FromSql can only return entity types, not ad-hoc query results. So it’s usefulness is limited and in my case, useless. If you insist on pushing forward with it, you can drop down to basic ADO.NET for your ad-hoc queries, but that kind of defeats the purpose of using an ORM at all.