New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
badre429 opened this Issue May 10, 2017 · 97 comments

Comments

Projects
None yet
@badre429
Copy link

badre429 commented May 10, 2017

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

This comment has been minimized.

Copy link
Member

divega commented May 12, 2017

@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 divega changed the title Question: Is Entityframework 6 compatible with dotnet standard 2.0 Investigate what it would take for Entityframework 6 to target .NET Standard 2 May 12, 2017

@divega divega changed the title Investigate what it would take for Entityframework 6 to target .NET Standard 2 Investigate what it would take for Entityframework 6 to target .NET Standard 2 and/or work with .NET Core 2 May 12, 2017

@divega

This comment has been minimized.

Copy link
Member

divega commented May 12, 2017

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

@jrkd

This comment has been minimized.

Copy link

jrkd commented May 12, 2017

"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

This comment has been minimized.

Copy link

douglaswaights commented May 12, 2017

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.

@ajcvickers ajcvickers added this to the 6.3.0 milestone May 15, 2017

@rhythmnewt

This comment has been minimized.

Copy link

rhythmnewt commented Jul 5, 2017

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

@badre429

This comment has been minimized.

Copy link

badre429 commented Aug 8, 2017

@divega any update

@marchy

This comment has been minimized.

Copy link

marchy commented Aug 24, 2017

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

This comment has been minimized.

Copy link
Contributor

ErikEJ commented Aug 27, 2017

API Port report here:
ApiPortAnalysis.xlsx

@Rzpeg

This comment has been minimized.

Copy link

Rzpeg commented Aug 28, 2017

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

@muehan

This comment has been minimized.

Copy link

muehan commented Sep 20, 2017

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...

@jayoungers

This comment has been minimized.

Copy link

jayoungers commented Sep 26, 2017

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

This comment has been minimized.

Copy link

fanoI commented Oct 22, 2017

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

@ErikEJ

This comment has been minimized.

Copy link
Contributor

ErikEJ commented Oct 22, 2017

@fanol you can already do that with Mono and EF6

@fanoI

This comment has been minimized.

Copy link

fanoI commented Oct 22, 2017

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

@marchy

This comment has been minimized.

Copy link

marchy commented Oct 30, 2017

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

This comment has been minimized.

Copy link

ovidiubuligan commented Oct 31, 2017

@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

This comment has been minimized.

Copy link

jimmymain commented Nov 8, 2017

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

This comment has been minimized.

Copy link

stoune commented Nov 16, 2017

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

@twosandy

This comment has been minimized.

Copy link

twosandy commented Nov 22, 2017

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

This comment has been minimized.

Copy link

jimmymain commented Nov 22, 2017

@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.

@twosandy

This comment has been minimized.

Copy link

twosandy commented Nov 22, 2017

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)

@marchy

This comment has been minimized.

Copy link

marchy commented Sep 20, 2018

Wow @springy76 nice find!

This is fantastic news. I was just thinking how the community could so use a fork so that while the MS team can keep focusing on the far-futured EFCore, innovation can still happen on the much more advanced, immediate and practical framework – EF6.

Extremely happy to pay money for this framework (starts at $599 USD it seems)

So great to see the benefits of an open community at its best!

@jancg

This comment has been minimized.

Copy link

jancg commented Nov 2, 2018

We would like to use ASP.NET Core and EF 6.x since EF Core is not good enough for us yet.

@AlirezaHaghshenas

This comment has been minimized.

Copy link

AlirezaHaghshenas commented Nov 7, 2018

I'd like to see EF6 on .net core because:

  • In my experience, the most dangerous/frustrating part of migrating an asp.net mvc project to asp.net core targeting .net core is the EF core. I've recently migrated one pretty complex project which used many 3rd party projects and many corner-case features of asp.net, lacking or changed in asp.net core. Yet the problems I've had were dominated by EF core. On the one hand, most of these problems don't show up until runtime, and sometimes in special cases. I've reported two instances in here and here

  • Automatic migrations. I'm developing an open source project, temporarily named dscribe to do CRUD from metadata. It dynamically creates and loads an assembly based on this metadata. Using EF6x, I could use automatic migrations to initialize the business database. In EF core, migrations have to be built into the assembly, which is pretty hard, if possible at all to be used in our project.

@michaelaird

This comment has been minimized.

Copy link

michaelaird commented Nov 8, 2018

In a recent ASP.NET Community Standup, Damian Edwards has said (https://www.youtube.com/watch?v=GN54OV5cCBM&feature=youtu.be&t=1146) EF6 will be ported to .NET Core in the 3.0 timeframe.

@divega / @ajcvickers : Can you clarify if it's going to be .NET Core only or will it target .NET Standard?

Given that .NET Standard 2.1 will not be supported on .NET Framework
( https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/ ), I believe it is critical that the EF6 port target .NET Standard 2.0 in order to maintain support for .NET Framework.

@ajcvickers

This comment has been minimized.

Copy link
Member

ajcvickers commented Nov 8, 2018

@michaelaird Work has only just begun on this so nothing is finalized yet, but currently the plan is to multi-target net40 (.NET Framework 4.0), net45 (.NET Framework 4.5 and later), and netcoreapp2.1 (.NET Core 2.1 and later.) However, that last TFM may change to either netcoreapp3.0 if it turns out this is needed, or possibly netstandard2.1, if it turns out this is possible.

This means:

  • EF6 will continue to target .NET Framework 4.0 and above, just like it does today
  • EF6 will also target either one of the newer .NET Core platforms, or possibly .NET Standard 2.1
@michaelaird

This comment has been minimized.

Copy link

michaelaird commented Nov 8, 2018

This is where I believe things start to break down when libraries (like EF) don't target netstandard:

I have an (internal) library for "plumbing" stuff which is published as a nuget package. I want to target netstandard for the broadest compatibility. All of my code is netstandard compatible except I have a dependency on EF. Am I now forced to pick one of the targets that EF supports? or all of the targets?

Running the ApiPortability against the assemblies shows EntityFramework.dll is 98.19% with netstandard 2.0 + Platform Extenstions and EntityFramework.SqlServer.dll is 99.92% compatible. Most of the incompatibility appears to come from AppDomains and Remoting.

@ajcvickers

This comment has been minimized.

Copy link
Member

ajcvickers commented Nov 8, 2018

@michaelaird EF Core will continue to support .NET Standard. The porting of EF6 to .NET Core is specifically about the ability to port existing applications that target .NET Framework to .run on NET Core. It's not about making EF6 available on any other platforms.

@springy76

This comment has been minimized.

Copy link

springy76 commented Nov 8, 2018

@michaelaird Thats exactly the same situation I'm into, too: 100 projects depend on my model, so everything currently is tied to net472 for exactly that single dependency, everything upstream would be compatible with netstandard2.0 at 99.999%

@ajcvickers You say "work has only just begun", so here my 2 cents: Please split this large monolith assembly into parts, especially netstandard2.0 compatible ".abstractions" parts. For example IDbSet could be placed there, and maybe an abstract IDbContext. And please don't forget to pull missing members of DbSet<T> into IDbSet<T>, like RemoveRange(). Most of my code does not have to deal with much of the real EntityFramework. Simple interfaces would be enough in most cases.

@michaelaird

This comment has been minimized.

Copy link

michaelaird commented Nov 8, 2018

@ajcvickers You say "work has only just begun", so here my 2 cents: Please split this large monolith assembly into parts, especially netstandard2.0 compatible ".abstractions" parts. For example IDbSet could be placed there, and maybe an abstract DbContext. And please don't forget to pull missing members of DbSet<T> into IDbSet<T>, like RemoveRange(). Most of my code does not have to deal with much of the real EntityFramework. Simple interfaces would be enough in most cases.

Yes. Yes. A million times. yes. EF6 "core" with abstractions and everything that can be ported whole cloth to netstandard2.0 and EF6 "full" with the multi-targetting for the things that can't would be an amazing solution.

@mrahhal

This comment has been minimized.

Copy link

mrahhal commented Nov 8, 2018

I think it's good to put more emphasis on how important it is for EF6 to either target netstandard or at least split the project and create "Abstractions". I share in @springy76 and @michaelaird's thoughts. We have a lot of core libraries that reference EF6. We plan to port to netstandard. I guess we can always multitarget to net45 and netcoreapp3.0 but that completely defeats the purpose of netstandard for these libraries, and also forces all dependents to do the same.

@ajcvickers

This comment has been minimized.

Copy link
Member

ajcvickers commented Nov 8, 2018

@springy76 @michaelaird @mrahhal Any fundamental changes to EF6, including splitting into abstractions, are not on the table. EF6 is not going to change in any fundamental way. The only approved investment is to allow EF6 to run on .NET Core 3.0, pretty much unchanged except where is necessary for the different way .NET Core and NuGet work in the .NET Core world.

@AlirezaHaghshenas

This comment has been minimized.

Copy link

AlirezaHaghshenas commented Nov 9, 2018

@springy76 @michaelaird @mrahhal Any fundamental changes to EF6, including splitting into abstractions, are not on the table. EF6 is not going to change in any fundamental way. The only approved investment is to allow EF6 to run on .NET Core 3.0, pretty much unchanged except where is necessary for the different way .NET Core and NuGet work in the .NET Core world.

This is totally understandable. When plan is extended from just fixing runtime compatibility to large-scale refactor, suddenly there will be orders of magnitude more work to do, and much of that will require planning and design sessions etc. Also some changes might break backward compatibility.

@springy76

This comment has been minimized.

Copy link

springy76 commented Nov 9, 2018

Ok then.

EF6 will also target either one of the newer .NET Core platforms, or possibly .NET Standard 2.1

I would prefer netstandard2.1 then if possible. This still means that the final app will have to target netcoreapp3.0, but I have a bad feeling about all my libs, between model and app, targeting a specific platform. I really would prefer netstandard2.1 there.

@mrahhal

This comment has been minimized.

Copy link

mrahhal commented Nov 9, 2018

Ok, what platforms this new version of EF6 will target got more confusing along the way. At first, it was announced that EF6 will target netcore but only on Windows. @ajcvickers thanks a lot for all the explanations, but can you confirm if this is still the case (in which case, it'll be kinda hard reasoning about whether a netstandard/netcoreapp lib will only work on windows or not), or will EF6 work on linux on netcore too?

@ajcvickers

This comment has been minimized.

Copy link
Member

ajcvickers commented Nov 9, 2018

@springy76 Agreed that netstandard2.1 is preferable over netcoreapp2.1/3.0. We'll see how it goes.

@mrahhal It was never the plan to only target Windows. That was just a mix up from marketing/PowerPoint people.

@michaelaird

This comment has been minimized.

Copy link

michaelaird commented Nov 9, 2018

@divega

This comment has been minimized.

Copy link
Member

divega commented Nov 9, 2018

@michaelaird rest assured that we will try to target the minimal version of .NET Standard that contains all the APIs that EF6 needs, (edit) in addition to the .NET Framework versions that we already support.

@arukiidou

This comment has been minimized.

Copy link

arukiidou commented Dec 31, 2018

~JohnGalt1717 commented on 16 May
@divega people asked and since things like:

Many to Many, TPT, TPC, Entity Splitting, simple logging and Change Tracking Proxies are used almost everywhere in any serious project (and lazy loading is not unless you're a bad developer) this is major omissions that still make EF Core impossible to port to for most EF 6 projects, which is exactly on topic.

And that's just the most used from the list on the left. All but the Visual Designer and update model from database are core functionality that most serious projects will be using all of the time too and while they may not completely block a port, they sure will make the port difficult.

In fact, is the
[Visual Designer(Model First)] and [update model from database] usage in the develop project low?

@JohnGalt1717

This comment has been minimized.

Copy link

JohnGalt1717 commented Jan 2, 2019

@arukiidou I'm under the impression that almost no one uses those features because they're counter to how databases should be driven with EF and migrations. (may be valid if you're starting with an existing database and have a DBA driving database changes...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment