Ef6: 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 https://github.com/aspnet/EntityFramework6/issues/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...

[jayoungers]

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.

[twosandy]

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.

[twosandy]

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)

[htuomola]

@twosandy as it depends on .netstandard 2.0, you need to upgrade to .NET 4.6.1 for it to work. With that done, it should work fine. See .NET standard versions

[twosandy]

Thank-you htuomola - I'll keep persisting with trying to get it working.

[jimmymain]

@twosandy if your're battling with this, email me [email protected]
(I trust gmail - perhaps naively to shoot the spam).
I do have a working dotnetcore, EF6 Identity, IdentityServer4, angular5, bootstrap4, SpaServices solution working with aspnetcore bearer tokens. Happy to share. I can't (at this point anyway) post it on github. You will need to be specific, I can email you some files (like startup.cs) and IdentityServer4 configs but I can't send anything complete.

Perhaps we can work together to provide a boilerplate for other engineers?

One pointer I can provide immediately is that you should include all your EF6 requirements in a separate library targeting the full framework. That saved me a lot of time. Some dependencies leak, but VS2017 is reasonably good at managing those.

oh, and yes, install and use libraries from dotnetcore 2.0+ in your web project - it will make your life easier.

[marchy]

@jimmymain so that still doesn't mean you can run the web server on a non-Windows machine, correct?

We've done the same workaround, split up the web app into its own .NET Core dependency, with the Domain/EF6 project targeting full framework and simply being able to be referenced from both Core and full framework. But that unfortunately means you're still stuck developing and hosting on full .NET framework – so I'm not sure it actually has anything to do with this ticket. This ticket is trying to run an actual EF6 project (whether isolated in a separate library or not) on .NET Core.

PS: To showcase how far we've had to go to get around this issue, we've actually since split up the database access layer into its own API-wrapped micro-service (holy smokers) so that our web app can actually be developed & hosted on non-Windows environments (ie: .NET Core) – and we have an extra API layer to call into the domain. Instead of calling a method on a library, we now make an API call to our database micro-service and have to handle all related serialization & errors via REST instead of C#. Talk about incurred dev costs for no good reason!! #dotnetcorefail

[jimmymain]

I wonder if this changes anything?
https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcing-the-windows-compatibility-pack-for-net-core/

[madelson]

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.

This would be very helpful for us. The migration path for a huge EF6/MVC5/.NET Framework 4.7 codebase is quite daunting. With .NET Standard 2.0 support this gets significantly easier (especially since EFCore has numerous differences to EF6).

In our case, we do not use migrations or any of the tooling, just the runtime library. Therefore, even just having that support .NET Standard would be a boon. Similarly, we don't leverage app.config-based configuration at all, so if this was omitted we'd also be fine. My guess would be that even for those that do leverage these features having the runtime work would be helpful.

[IanYates]

I can see this providing a great migration path for companies like us.
We have an ASP.NET MVC / WebAPI / SignalR application. EF6 used for database access. Targeting full framework. Using database first.

Moving to .NET core is one of those things that would be great as we could soon take advantage of the huge improvements on the ASP.NET side, along with the faster release cycles of .NET core. However moving to EF7 will be difficult due to our database first usage and it being more of a "black box" compared to the web side of things.

If we could move to ASP.NET Core on full framework (which is possible, although still waiting on proper SignalR), the next stop would be to then target .NET Standard, running on Core 2.x, whilst still keeping EF6.
When we want to take the big breaking change, with all of the corner case regression testing, stopping of DB first, etc then we could move to EF7

Not that it carries a lot of weight anymore, but we're a Silver ISV partner. If it helps, and I knew where to direct the feedback, I could send this same message via the Partner channels?

[ErikEJ]

@IanYates Why not ASP.NET Core full .NET + EF 6 ??

[springy76]

In our case, we do not use migrations or any of the tooling, just the runtime library. Therefore, even just having that support .NET Standard would be a boon. Similarly, we don't leverage app.config-based configuration at all, so if this was omitted we'd also be fine.

Same here: Using Code-first, System.Data.Sqlite and no app.config or migrations at all, just the bare framework.

[paulirwin]

It appears to me that all of the non-portable/unrewritable uses of Remoting and AppDomain in the ApiPortAnalysis file are just to enable design-time support. Can anyone confirm this is the case? If so, shouldn't that be possible to move into its own assembly or drop entirely?

I would gladly accept a forked NuGet package of EF6 that drops design-time and ConfigurationManager support if that is the case...

[rendmath]

Maybe we also need to take into account the message it would send to the community. Entity Framework Core has been in active development for more than 3 years, and is still not up to feature parity with Entity Framework 1.0 (ex: many-to-many associations without join entity, GROUP BYs running in the database, etc.).

Diverting resources to port and maintain Entity Framework "classic" to the .NET Standard might not be the greatest message to send about the future of EF Core.

[mrahhal]

@rendmath and so what? Do we make people stick with an under-featured EF just so that EFCore can remain the only option on netstandard? Seems totally backward to me. We develop frameworks for developers to use, we don't develop frameworks for their own sake.

Even if EF6 gets ported to netstandard, I don't think EFCore would lose its good points. But it is a fact right now that EFCore is not suitable for heavy business oriented work. It's still a good option for a lot of lightweight apps, or small integrations (an example would be IdentityServer's storage impl using EFCore). Both can be used in tandem.

[springy76]

@rendmath you make me angry. Take into account what great message you are sending to the people here.

[madelson]

@rendmath I understand your perspective but I actually think this move will be in the best interest of both EF6 and EFCore. So long as EF remains a huge pain point for people moving to .NET Core there is going to be lots of pressure on EFCore to reach feature parity, perhaps even at the expense of design purity or performance. Having struggled with many underlying infrastructural issues in EF6, I'm really excited about the idea that EFCore being it's own thing designed with the benefit of hindsight. I'd hate to see this sacrificed in the name of making framework transitions easier.

Getting .NET Core support for EF6 via .NET Standard would decouple the framework transition issue from the EF transition issue.

[paulirwin]

@rendmath With all due respect, I don't care about the message it sends to the community. I have a codebase I have to port to .NET Core and I can't because of EF Core being incomplete and EF6 not working on .NET Standard. If anything, perhaps it would send the message that everyone acknowledges that EF Core is not complete yet and so they're making it easier to adopt .NET Core in the meantime.

FWIW, I was able to fork EF6, rip out all of the migrations, SQL CE, ConfigurationManager, and design-time stuff, and get it to compile on .NET Standard 2.0 in just a few hours. It might be possible to add back in the migrations stuff but I don't need it (I use database projects) so it was easier to rip it out. I'm running into issues with loading resource strings that I'm stuck on, if anyone is interested in helping let me know.

[paulirwin]

Here is a working prototype of EF6 on .NET Standard 2.0, with a .NET Core 2.0 test application performing a basic ToList of a DbSet. I plan on doing more extensive testing tomorrow. It only took me about 5 hours of work to get this working.

There are obvious limitations, but I think most people not using migrations can live with them:

• No support for providers other than SqlClient
• No migrations or PowerShell support
• No design-time support
• No ConfigurationManager support - meaning app.config settings do nothing
• Must pass full connection string to DbContext base constructor instead of connection string name (due to lack of ConfigurationManager support)
• Unit test projects have been removed (again, this is a prototype) so I can't confirm all tests pass
• Must add references in your calling projects to the NuGet packages System.Data.SqlClient and System.ComponentModel.Annotations. Remove any .NET Framework references to System.ComponentModel.DataAnnotations if using .NET Framework.

My only concern is that I had to remove some serialization-related methods from a couple of types in order for this to work on .NET Framework as well due to a bug in .NET Framework (see https://github.com/dotnet/standard/issues/300). However, I can't determine why these types would need to be serialized in normal usage and it seems to work without the offending methods.

[springy76]

@paulirwin I did not have time yet to take a look at it. I could live with all the limitations but the first one, because I need System.Data.SQLite (which I only configure by code): Is this a hard/complicated limitation?

[paulirwin]

@springy76 It's possible with a little work. Can you post a code sample of how you're configuring it via code?

The main things that would likely have to change are bringing back some of the AppConfig class members but make them in-memory only, and something custom to this fork would probably have to be done with DefaultDbProviderFactoryResolver since the DbProviderFactories class is not present in .NET Standard so I had to add a hardcoded reference to SqlClientFactory.

[springy76]

@paulirwin That should be entire code related to connect System.Data.SQLite to EF: (of course currently not netstandard since tied to official EF6)

public class SQLiteDbConfiguration : System.Data.Entity.DbConfiguration
{
    public SQLiteDbConfiguration()
    {
        this.SetProviderFactory("System.Data.SQLite", System.Data.SQLite.SQLiteFactory.Instance);
        var providerServices = GetService<System.Data.Entity.Core.Common.DbProviderServices>(System.Data.SQLite.EF6.SQLiteProviderFactory.Instance);
        this.SetProviderServices("System.Data.SQLite", providerServices);
    }

    private static T GetService<T>(IServiceProvider provider)
    {
        return (T)provider.GetService(typeof(T));
    }
}

[sepehr1014]

@paulirwin Awesome work. I'm just wondering if it's stable enough for production. Has anyone reported any issues so far? Are you planning to add unit tests? It would be great if you could release it as a separate project to be widely used and maintained. At least until EF Core 2.1 is out.

[ErikEJ]

@sepehr1014 What feature(s) in EF Core 2.1 are you waiting for? Why not just use 2.1 preview-1, which is coming very soon?

[sepehr1014]

@ErikEJ There are many. Lazy loading, GroupBy translation, query types, transactions support to name a few. There are also things like spacial data types which we're using right now and are not even planned for EF Core 2.1. Regarding 2.1 preview 1, my experience in the past 6 months using ASP.NET Core tells me preview build tend to be very buggy to be even considered for production.

[madelson]

@ErikEJ even beyond specific features (many of which @sepehr1014 has listed) for us the problem is compat in general. We have a truly massive codebase comprised of over 70 applications built on EF6. We want to move to both .NET Core (and eventually EF Core), but those are both long expensive migrations that will have to happen incrementally. Having these two migrations coupled together makes the whole process take longer and acts as a signficant blocker to getting started.

[springy76]

@ErikEJ it is rewritten from scratch and therefore has all problems all rewritten-from-scratch software has: Missing features, new bugs, old bugs reintroduced, different unforeseeable behaviors.
Some queries just might not work at all, others might become slower by a factor of 1000 -- yes, that's a true and daily problem of SQLite when queries become too complex.

Furthermore: I'm currently using System.Data.SQLite which supports features (namely "Virtual Tables") which are not supported by this strange raw-green-ugly-pretty-pcl-sqlite-universe available for EFcore -- and they also have no plans in doing so.

[paulirwin]

@sepehr1014 I have installed it on our application's codebase (just to give scale, we have about 120 POCO models) and it works well. I plan on releasing it to production very soon. Note that we are still targeting .NET Framework 4.7.1 due to other Core-incompatible dependencies. Also there are features we do not use like navigation properties. So I do not consider this an exhaustive test but rather a proof of concept. If I encounter any issues I'll report back here. Eventually I'll look into creating a separate repo so it has its own issue tracker. AFAICT that should be permitted under the Apache license.

[sepehr1014]

@paulirwin That's good news. We're planning to migrate to .NET Core in the near future. Please keep us updated on the progress of this project.

[madelson]

@divega curious whether you'd be willing to at least make this an up-for-grabs issue. If the community gets a version working with all tests passing, would you be willing to (pending review) have this merged in and have it be another target framework version for the EF6 package?

[divega]

@madelson thanks for asking. We usually use the up-for-grabs label on issues that we consider easy for getting started with the codebase. We believe this one isn’t easy, but that does not mean that we are against anyone in the community trying. If you can get a significant portion of the tests passing, let us know by all means!

[paulirwin]

I have published my changes to a separate repo so it has its own issue tracker and can accept its own PRs. But it is just another remote of the same repo so it has the full git history. Feel free to help contribute here: https://github.com/paulirwin/EntityFramework6-DotNetStandard

I have tested this against our existing codebase with both .NET Framework 4.7.1 and .NET Core 2.0 and have encountered no issues.

[hirre]

@paulirwin nice work! What does it take to add migrations btw?

[paulirwin]

@hirre You tell me 😄 I'm gladly accepting PRs at my repo. It likely would be easier to get database initializer-type migrations going than the PowerShell part, but I never tried. I don't use them so I don't have a good test case anyways even if I had the desire to implement them 😄 I'll leave that up to the community. I created issue https://github.com/paulirwin/EntityFramework6-DotNetStandard/issues/1 to discuss that further.

[fanoI]

@paulirwin a clarification your fork does not permit to make work EF6 on Linux right?

[paulirwin]

@fanol I don't see why not. It runs successfully on .NET Core without warnings on Windows, so it hypothetically should work on Linux/macOS. I'm not using the Windows Compatibility Pack or anything. You could give it a try and report any issues you find on my repo.

[mrahhal]

Maybe this ^ discussion should be made somewhere in @paulirwin's repo? People are watching this thread to track the updates that relate to the official support consideration.

[xrkolovos]

no news in this one?

[Suchiman]

There's an answer on this now: https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

[springy76]

So EF6 will be based on .NET STANDARD but Windows-only? You are kidding at me, Microsoft, are you?

[Suchiman]

@springy76 i'm not entirely sure, the graphic is a bit confusing, as EF6 is listed on the Windows-only side but then got (cross plat) written behind it as to indicate the opposite...

[tomgruszowski]

@springy76 not sure what the big deal is, are you running EF6 on a linux now? If you want 100% cross platform run Core. They don't have infinite resources.

[ajcvickers]

@xrkolovos @Suchiman @springy76 @tomgruszowski The primary goal in bringing EF6 to .NET Core is to make it possible to port existing applications (of any kind) to .NET Core without porting the code to use EF Core. It is not intended to be Windows only. It is also not intended to be the primary ORM on .NET Core (for any kind of application) and investment in new features will happen primarily on EF Core, not EF6, as is the case today.

[madelson]

@ajcvickers @divega excited to see this become part of the 6.3 milestone!

[JohnGalt1717]

Note that this is basically required for .NET Core 3, because if you want WPF apps to run in .NET core, then EF 6 has to come with it.

[ajcvickers]

@JohnGalt1717 Can you elaborate on what you mean by that?

[JohnGalt1717]

BUILD stated that .NET Core 3.0 would bring WPF, WinForms etc. into .NET Core 3.0 running as is.

The vast majority of LOB apps written in the past 10+ years use EntityFramework, so if you want these apps to work, .NET Core 3.0 MUST support Entity Framework 4+ AS IS. Otherwise there really no point whatsoever in porting WPF/WinFORMs to .NET Core because apps still won't run and no one in their right minds is going to waste their time porting to the anemic EF Core just for .NET Core support.

So this must be proven to work on at least .NET Core 3.0 or that entire initiative is moot as a waste of resources by Microsoft. (Which it already is, because they should be porting .NET Core and UWP to iOS and Android, not working about LOB apps that are just going to be ported directly to the web or mobile anyhow. But I digress pointing out how MS still doesn't have a clue about how to win back consumers, including business consumers...)

[tystol]

@JohnGalt1717 I'm pretty sure that is their intention. The BUILD article linked a few posts above has a few sentences on it:

Similarly, EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6. But we don’t plan to add any major new features to EF6. EF Core will be extended with new features and will remain the recommended data stack for all types of new applications. We will advise that you port to EF Core if you want to take advantage of the new features and improved performance.

[JohnGalt1717]

@tystol One hopes. Too bad UWP and .NET core isn't running on Android and iOS. That would have been really special.

[ErikEJ]

Details about EF6 and .NET Core 3.0 at 33:50 : https://youtu.be/k55kDH_ixrQ

[ajcvickers]

@JohnGalt1717 Thanks for you thoughts. A few comments:

• EF4 through EF5 will not be ported to .NET Core. Only EF6 will be ported.
• This is to make it easier to port existing applications. However, EF Core supports WinForms and WPF data binding and should still be preferred where possible. It is not necessary to use EF6 for a data bound application in WinForms or WPF.
• Can you be specific about which parts of EF Core are anemic?

[JohnGalt1717]

@ajcvickers Do a functionality comparison between EF 6 and EF Core. It's still bad even with EF Core 2.1.

[divega]

Here is a feature comparision between EF6 and EF Core

Given that this issue is about porting EF6 to .NET Core and/or .NET Standard and many people have subscribed to the thread to get relevant information, let's try to stay on topic.

If you have specific and actionable feedback on EF Core, please use https://github.com/aspnet/EntityFrameworkCore/.

[JohnGalt1717]

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

[marchy]

@divega any ballpark estimate for a preview of EF6 running on .NET Core? (rough is fine)

Not for Windows/desktop apps but for MacOS/ASP.NET Core web/server apps.

The team is seriously targeting the wrong customers/businesses adding support for desktop. As one of the comments above states any business that is half-focused on innovation has gone to SaaS/web and mobile a long time ago.

For those of us that chose to stay .NET for our web/API stacks we’ve been screwed and paying crazy hits for the last 3 years (like buying our devs both Windows & Mac machines, running chugingly-slow VMs, trying dual boot partitions that break havoc on dev workflows - and the bank etc.)

Will .NET Core 3.0 run EF6 on Mac/Linux stacks seamlessly? And what’s the ETA for a preview on it?

Kind thanks.

[ErikEJ]

EF6 will be cross platform according to the blog post here, which is the official roadmap so far for .NET Core 3.0 https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

[springy76]

So will there be a netstandard3.0 which covers all the new netcoreapp3.0 APIs?

[ErikEJ]

@springy76 What makes you think that?

[springy76]

@ErikEJ because I won't develop libraries (for the model itself and others for different parts of business logic) which target netcoreapp?.? but only netstandard?.?. Having invested much work in getting rid of specific framework net4?? I won't get specific again on another framework.

So EF6 will become compatible with netstandard2.0?

[springy76]

Any opinions/warnings for that: http://entityframework-classic.net/?

I found it while searching for HTML Agility Pack.

[marchy]

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]

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

[AlirezaHaghshenas]

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]

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]

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

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

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

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

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]

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

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

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]

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]

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

Just to be clear. Netstandard 2.1 is not preferable because .Net framework 4 won’t support it.

Netstandard 2.0 is preferable.

[divega]

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

～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]

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

[simonpapworth6742]

Lazy loading and Navigation properties will make the code change so much easier.

Having EF 6.3 working on .Net Standard (even with extra support packages required) would take 100% of the risk out of moving our SaaS product to .Net Core.

EF is forcing a big bang approach to migration - literally thousands of man hours will go into the migration - not keeping our product leading its market.

[willnogueira]

Up!

[cmorgan091]

The key issue for me, is that whilst some features will be supported in EF Core at a later date, there is no expectation that EF6 migrations will ever be able to be ported into EF Core migrations.

The current recommendation is to create an empty EF core migration at the point where all migrations have been applied to the database and continue forward from there. But this means that for distributed apps, where we use migrations to update the database schema to bring it in line with the application code, we will need to always do 2 part upgrades (go to the latest version supported by EF6, then to the latest version of the codebase which will be EF Core).

This is sub optimal to say the least, although I accept it will one day become a necessity. But for now we have multi tier applications where the only package not supported in .Net Standard is EF6.

So yes, this would be VERY much appreciated by those of us who have invested so much in EF6 within our apps.

[DamienDennehy]

Also looking forward to get this done.

Our use case is that we have a Database First EDMX with 800 context queries that are not fully unit tested. We can't just do a find and replace of EF6 to EFCore - we tried!

[michaelaird]

I'm looking at the commit that added support for NetStandard 2.1. I don't see anything that would require NetStandard 2.1 over 2.0.

@bricelam , could you outline some examples of what's needed in 2.1 that isn't supported in 2.0?

[divega]

@michaelaird, what about DbProviderFactories? System.Reflection.Emit? It is precisely because .NET Standard 2.1 includes the APIs the EF6 codebase needs that we didn't have to remove any features. If we had tried to target .NET Standard 2.0, those missing APIs would mean we would had to choose between removing features (e.g. proxies) and changing the implementation to do something else, e.g. use a lot of reflection code to call into APIs.

[springy76]

The problem with 2.1 is that I can't migrate a large solution (131 projects), which currently targets net472, step by step: I already have converted several libs to netstandard2.0, but now I'm stuck for ~70 ones which directly or transitively depend on EF6.
If I have to change these to netstandard2.1 then I have to change everything else (which targeted net472) to netcoreapp3.0 which will result in a solution where I will have to spend days (if not weeks) of work to just get it compile again! Even if I will get the aspnetcore2.1 part of it to compile again it for sure will not work as desired as there are just too many breaking changes alone from 2.1 to 2.2 not speaking of 2.2 to 3.0 -- and 3.0 is still a moving target, too.

[Suchiman]

@divega While those Features are not directly in .NETStandard 2.0, they can be used from it:
DbProviderFactory: https://www.nuget.org/packages/System.Data.Common/
System.Reflection.Emit: https://www.nuget.org/packages/System.Reflection.Emit
those addon packages support .NETStandard 1.2+

[divega]

@Suchiman I am not talking about DbProviderFactory but specifically DbProviderFactories (plural name).

[madelson]

@divega if it's really just DbProviderFactories, would/did you consider a solution where the netstandard2.0 target (1) tries to access that type via reflection and, if that doesn't work, exposes an API for registering a DbProviderFactory with a manifest token? Or is this more difficult than I'm making it sound?

[divega]

@madelson although we could do that, I am not sure you would get what you, @Suchiman or @springy76 want.

EF6 has to multi-target .NET Framework 4.0 and 4.5 in addition to some version of .NET Standard. Even if we targeted .NET Standard 2.0, the correct assembly to use on any application that targets .NET Framework > 4.5 is the .NET Framework 4.5 assembly.

If you have a library that depends on EF 6 and you want to start using it in a mix of .NET Framework and .NET Core projects, I believe you should have your library multi-target at least .NET Framework 4.5 and .NET Standard.

Update: I believe if you are using PackageReference, and assuming the surface on the .NET Standard EF 6.3 assembly is a subset of the .NET Framework surface (and I believe it is), then you may get away with just targeting .NET Standard in your libraries, but ultimately you could multi-target as well and you get the same results.

cc @bricelam and @ajcvickers in case I am missing anything.

So the question is, is there any additional .NET implementations you expect to be able to run EF6 on if we targeted .NET Standard 2.0? The goal has been all along to test and support EF 6.3 on .NET Core 3.0.

[springy76]

Since netcore3 contains all you need: When I reference existing EF 6.2 from a netcoreapp3.0-preview4 lib/app then NuGet only outputs a warning and continues, 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?

[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 #189
  
  
  
  • Handle EntityDeploy MSBuild items #828
  
  
• Enable PMC commands on .NET Core #231
• Enable Designer on .NET Core #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?