Make Entityframework 6 target .NET Standard and/or work with .NET Core

[badre429]

On the build 2017 event @coolcsh(Scott hunter) said that 70% in nuget library compatible with dotnet standard 2.0 is EF6 will support it.

[divega]

@badre429 there a few APIs EF6 uses that are either missing in .NET Standard 2.0 or in the .NET Standard version of some EF6 dependency.

The fact that 70% of all the packages in NuGet.org are API compatible with .NET Standard 2.0 is a very important metric but it does not imply that specific popular packages are compatible.

We have done some analysis of the gap, starting with a run through API Port, but we still need to discuss and understand what we can do about it (e.g. either come up with new API additions for .NET Standard 2.x or EF6 dependencies or modifying a future version of EF6 to stop using those APIs).

Once we have that data in hand, more information from customers wanting to run EF6 outside of .NET Framework can help us understand what priority we should give to this.

Keep in mind that making EF6 fully usable on projects that target other implementations of .NET than .NET Framework would also require significant changes to our migrations tooling. That is covered by #231.

[divega]

@badre429 I will be repurposing your question to track the ongoing investigation.

[jrkd]

"I would like to encourage anyone wanting this to happen to comment in the issue pointed above with their specific reasons. This will help us prioritize." - -divega

Please, this would help me convert existing projects using EF6 to .net core.

[douglaswaights]

We are running asp.net core on the full framework in 1.x and also plan to do this for the upcoming asp.net core 2.0 release. The reason for this is primarily we need EF6 for spatial. Maybe there are other blockers but spatial is the obvious one.

Would be great to run on .net core if we could, so modifying EF6 to work against net standard 2.x could be an interim solution until EF Core is ready ! :-)

Actually, we also need directory services and servicebase but these are flagged as high priority ports i believe, so hopefully later this year for them.

[rhythmnewt]

Agree with @jrkd. Not having to migrate off EF6 would incredibly help migrate existing projects to dotnet core.

[badre429]

@divega any update

[marchy]

What is the current state of this gap after the .NET Core 2.0 release?

We are also stuck on EF6 for several reasons (in-memory query client-side eval, group by clauses, spatial etc.). We had to downgrade from EF7 to EF6 after a really painful migration and realizing we could not handle the present EF7 limitations after a few months – would be wonderful to be able to move to .NET Core while still targeting EF6.

Is this planned at all for EF 6.2 ??

[ErikEJ]

API Port report here:
ApiPortAnalysis.xlsx

[Rzpeg]

We are migrating our libraries to .NET Standard 2, and it would be great to have EF6 ported as well.

[muehan]

Same Problem here. EF Core is no option for us. If EF6 does not work with .net Standard 2.0 I have to go back to the old Framework 4.x...

[JohnYoungers]

Is the bulk of that 5% around the app.config piece? If that was split out into a separate project how close would we be to standard v2?

[fanoI]

Please try to find a way to make this work. Having the real Entity Framework working on Linux will be wonderful!

[ErikEJ]

@fanol you can already do that with Mono and EF6

[fanoI]

Yes but Net Core is better that Mono already in my opinion.

[marchy]

Great work on the release of EF 6.2 team!
(Announcement: https://blogs.msdn.microsoft.com/dotnet/2017/10/26/entity-framework-6-2-runtime-released/)

Any updates on the priority of exploring support of .NET Core for EF 6.3?

[ovidiubuligan]

@ErikEJ Knowing that netstandard2.0 can add compatibility shims for non netstandard apis, shouldn't it be possible to run ef6 with the compatibility shims for ConfigurationManager , etc ?.
I'm trying to run ef6 on dotnet core 2.0 and fails at DBContext instantiation with

System.TypeLoadException: 'Could not load type 'System.Data.Common.DbProviderFactories' from assembly 'System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.'

Looking at the modules view in VS 2017 I see that System.Data is the one from .net Core.
Why Isn't System.Data shimmed ?

[jimmymain]

We have several clients both large financial and investment houses and smaller businesses who are all remaining on 4.6.1 because of entity framework.
Spacial data and TPT inheritance are the main levers stopping our migration.

If we could use EF6 on dotnetcore we would start the migration immediately.

[stoune]

We couldn't move to Azure Functions because EF6 doesn't work on .NET Standard 2.0.

[ghost]

Has anyone successfully tried having an EF 6 project and a .Net Core 2 project in the same solution with the .Net Core 2 project being able to reference and get data from the EF 6 project? I'm testing this out now and haven't been successful yet ..... I just wonder if I should keep trying or go back to older .Net editions... Thanks in advance

[jimmymain]

@twosandy - not sure exactly what you're asking - but you cannot target the .net core framework with EF6. What you can achieve though, is a .netcore web site using all the dotnet core libraries, and also include a dependency on EF6.

The web site will function correctly, but it must be hosted in a framework 4.6.1 / 4.7 (or below) full dotnet stack. You will not be able (for example) to execute it on a non windows platform.

All our web sites that have any database access use this pattern. We have multiple deployments in production that rely on the full framework, but are ASPNET CORE web sites. They will remain this way until such time as EF core catches up (a long way off - years probably, the additional inheritance patterns aren't even scheduled yet), or this issue is closed.

[ghost]

Thanks for your reply @jimmymain. This is exactly what I want to do - have a ASPNET CORE website with a dependency in EF6 included. Do you know of a good step by step guide to how to set this up in a single solution? I've been going through the example in https://docs.microsoft.com/en-us/aspnet/core/data/entity-framework-6 but when I downloaded the files, I realised it was dealing with ASPNET CORE 1.x instead of 2.x and when I tried to update the sample solution, I got numerous errors (see example below). I've since been trying to setup a solution with a ASPNET CORE 2.x and separate EF6 project but have been unsuccessful. There isn't much in the way of help to do this online at the moment hence my question. Thanks in advance.

Error example is: Package Microsoft.Extensions.Configuration.EnvironmentVariables 2.0.0 is not compatible with net452 (.NETFramework,Version=v4.5.2). Package Microsoft.Extensions.Configuration.EnvironmentVariables 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)

[cunnpole]

Do Code-First migrations work in this scenario using attribute model annotations? That's where I've seen most of the pain so far.

[springy76]

I don't use neither migrations nor configuration. There is always a precreated DbConnection instance (from provider specific connection string) and most of my libs would be satisfied if they could use IDbSet<T> from a netstandard2.0 compatible lib.

[madelson]

@divega reading over your comments I think that for us it is mostly a matter of timing. At this point EF6 is blocking us from converting 50+ internal NuGet packages to multi-target .NET Standard and net46 so that some of the applications referencing that suite of libraries can switch over to .NET Core.

If all the SDKs tooling for netstandard2.1, .NET core 3.0, and EF 6.3 will be ready at the same time then I think this should be irrelevant; it just means that we need to wait for .NET Core 3.0 to be ready/stable and start by targeting net46+netstandard2.1.

If, on the other hand, EF 6.3 could ship months earlier on top of the stable .NET Core 2 / .NET Standard 2.0, then this would accelerate our progress.

[jeremyhallden]

@divega reading over your comments I think that for us it is mostly a matter of timing. At this point EF6 is blocking us from converting 50+ internal NuGet packages to multi-target .NET Standard and net46 so that some of the applications referencing that suite of libraries can switch over to .NET Core.

If all the SDKs tooling for netstandard2.1, .NET core 3.0, and EF 6.3 will be ready at the same time then I think this should be irrelevant; it just means that we need to wait for .NET Core 3.0 to be ready/stable and start by targeting net46+netstandard2.1.

If, on the other hand, EF 6.3 could ship months earlier on top of the stable .NET Core 2 / .NET Standard 2.0, then this would accelerate our progress.

@madelson You will not be able to target .net46 + netstandard 2.1

"Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1."
https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/

[madelson]

@jeremyhallden are you sure? .NET 4.5 doesn't implement .NET Standard 2.0 but you can certainly multi-target between net45 and netstandard2.0. Obviously if you leverage any features available in one target but not the other you'd need to hide them behind #if NETSTANDARD2_0 or equivalent. What am I missing here?

[michaelaird]

My ideal solution would be a "contracts" or "core" package and a "runtime" package.

The "core" package would target the lowest possible version of NetStandard and contain things like DbContext and DbSet. the "runtime" package could multitarget .net45 and Netstandard 2.1 and have the configuration, migration, etc.

I think it was mentioned before and I know it's been declared as "out of scope" for this release, but I thought I would try to plug it one last time. :)

[divega]

If all the SDKs tooling for netstandard2.1, .NET core 3.0, and EF 6.3 will be ready at the same time then I think this should be irrelevant...

@madelson ok, thanks for the insights. We are planning to release EF 6.3 months in the same time frame as .NET Core 3.0 anyway. Although we have been able to basically port the runtime, we still have a lot of work to do enabling more tests, enabling tooling (both migrations commands and designer) to work on .NET Core projects, and to have the runtime providing a good experience without requiring certain entries in .config files that you don't get if you are using PackageReference.

you will not be able to target .net46 + netstandard 2.1
"Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1."

@jeremyhallden that sentence doesn't mean that you cannot multi-target those two. It means a library that only targets .NET Standard 2.1, cannot run on .NET Framework.

the compiler has no problem in referencing a netframework assembly and the output at least seems to work for some basic steps.
Question: When will it fail this way?

@springy76 I don't know for sure, but potentially in any of the places where we have #if defs in the code. Also any API that looks the same but has subtly different behavior. Although it can be very convenient that you can load an assembly that was built from .NET Framework into .NET Core, e.g. if you don't have the source code, I wouldn't recommend doing that with something as complex as EF6. We have the source code, and we are trying to do a proper port, including running our tests suites on .NET Core to make sure everything works correctly.

most of my libs would be satisfied if they could use IDbSet from a netstandard2.0 compatible lib.
My ideal solution would be a "contracts" or "core" package and a "runtime" package.

@springy76, @michaelaird Just to set expectations, we have no intention to refactor the EF6 into different parts that can target different TFMs. That said, we appreciate your feedback about .NET Standard 2.0 being useful and we will keep discuss.

I would also like to add that some of our recent discussions have been about potential confusion from the fact that even .NET Standard 2.1 could be too wide of target for EF 6.3 to have. In NuGet packages in general there is the tension between what TFMs they target and in what implementations of .NET they have actually been tested on. In this case, we are targeting .NET Standard 2.1, but only testing in an implementation of .NET Standard 2.1: .NET Core 3.0 (that is, besides the supported .NET Framework versions). So the temptation is to actually remove the netstandard2.1 target and add netcoreapp3.0 instead.

If we went in the other direction and changed to netstandard2.0, the number of .NET implementations the package would be expected to work on but wouldn't could be even larger. That is one of the reasons I personally feel reluctant to make such change.

[bricelam]

Closing this now that our functional tests are all passing on .NET Core 3.0. Please file new issues for any bugs you’re hitting. The remaining work to fully enable development on .NET Core is tracked in the following issues:

• Enable NuGet PackageReference Optimize EF6 to work with PackageReference and no app.config #189
  • Handle EntityDeploy MSBuild items EDMX Metadata Generator options for .NET Core #828
• Enable PMC commands on .NET Core Make EF NuGet package / migrations and EF Tools work with new csproj format #231
• Enable Designer on .NET Core Update VS Tools to work with SDK-style projects #883

[bricelam]

Also note that SQL Server Compact and SQL Server Spatial Types (geometry/geography/hierarchyid) aren’t available on .NET Core.

Spatial support however was added (using a different approach) in the recent EF Core 2.2 release which, of course, works on .NET Core.

[ErikEJ]

Also note that the SQL Compact Provider could potentially be made to work with .NET Core and EF 6.3 (on Windows only)

[springy76]

Now I have to wait for System.Data.SQLite.EF6 to catch up.

[d668]

Just to clarify - I am not able to point EF 6.4.4. and EF Core to the same entities because the former needs NET Standard 2.0 and the later needs NET Standard 2.1

Right?