Porting to Entity Framework Core

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 method UseMySql 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 to System.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 your DbContext

To Be Continued…

This was my first pass at a small project that was using EF6 and the issues that came up while porting to Entity Framework Core. I will keep this post updated when I discover more situations while porting other applications. Have you ported to EF Core? Please share your insights in comments or on Twitter.

Follow @CodeOpinion

5 thoughts on “Porting to Entity Framework Core”

Paul Wheeler October 19, 2017 at 8:09 am


Great article!
NOTE: “minor changes to your DbContex” should probably be “minor changes to your DbContext”
1. Derek Comartin October 19, 2017 at 8:31 am
  
  
  Fixed. Thanks!
Daniel Root October 19, 2017 at 12:09 pm


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
1. Derek Comartin October 19, 2017 at 1:19 pm
  
  
  Interesting. Thanks for the heads up!
OldDev October 31, 2017 at 7:42 am


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.