Target .NET Standard 2.1

[roji]

As recently announced, we need to make the necessary changes to target .NET Standard 2.1.

[roji]

Hey, I'm not sure it's permitted to just grab issues like that :)

[ajcvickers]

@bricelam @smitpatel @roji Since you all seem to want to fix this, please coordinate to make sure we're not doing the work multiple times. :-)

[roji]

Oh @bricelam is in this too, huh?

[ajcvickers]

Yeah, Brice requested to do this yesterday. :-)

[bricelam]

Note, there a lot to think through about what this means for the tools.

[bricelam]

Ideally, the latest dotnet-ef will continue to work with 2.0 projects even when they target .NET Framework.

[smitpatel]

IX-Async made quite a few breaking changes to align with inbuilt interface. Since we don't use that version currently, that means we have to update our codebase for newer version of IX-Async. So re-targeting has become non-trivial task. Ideally all that code would go away in new pipeline. Hence adding blocked label.

[kevinchalet]

Really sad to hear that EF Core 3.0 RTM won't support .NET Standard 2.0 😭

It's not exactly clear to me why you couldn't support .NET Standard 2.0, as compat' types for IAsyncEnumerable and its friends are provided by IX as part of the System.Linq.Async package (it uses [TypeForwardedTo] to ensure they don't collide with the types shipping with .NET Core 3.0).

The CoreFX team is also about to release Microsoft.Compatibility.AsyncInterfaces, that will adopt the same strategy (dotnet/corefx#37189). I suspect IX will use it once it's officially released (/cc @onovotny).

Couldn't you use these compat' packages for the netstandard2.0 TFM?

[poke]

I also wonder why a move to netstandard2.1 is necessary. Judging by the blog post, async enumerables are the primary goal and that makes sense since that is something that will probably positively impact the end users. However, as Pinpoint points out, compatibility paths do exist.

This is consistent with similar decisions announced last year for ASP.NET Core […]

Not exactly though. ASP.NET Core 3 is moving to .NET Core to leverage the improvements of that runtime. For EF Core, we were explicitly told that it would remain on netstandard, implying that it would continue to run on the .NET Framework. If this changes now, then this would be a very big loss for applications that still sit in a legacy area but actively started to share code with modern applications, which is something that EF Core very nicely allows.

Customers that need to run EF Core on .NET Framework, should plan to continue using EF Core 2.1 or 2.2.

The problem now is that EF Core follows the support lifetime of .NET Core, so EF Core 2.2 is not an LTS release, meaning it will be quickly out of support when 3.0 lands. And EF Core 2.1 is an LTS release but will also eventually go out of support when 3.1 releases.

While Microsoft eventually extended support for ASP.NET Core 2.1 on .NET Framework, it is unclear whether this also applies to EF Core 2.1. And even if it does, this means that customers will possibly have to downgrade from 2.2 which is something that somewhat works for ASP.NET Core, but can get pretty complicated with EF Core, especially if you use 2.2 features.

Ideally, I would like to see EF Core to be cross-compiled for netstandard2.1 and netstandard2.0. Utilize all the fancy stuff in 2.1 and make it super nice, but keep compatibility with netstandard2.0 for those that have to rely on that. Even if that means that some APIs won’t be available, or if the performance degrades because of that.

You always kept telling us that library authors should target the minimum-possible netstandard version to ensure high compatibility, and utilize cross-compiling to make use of modern stuff. So it would be really nice to actually see you do this yourself, especially on such a high traffic library as EF Core.

[davidroth]

+1 for keep targeting netstandard 2.0. At least for the 3.0 timeframe i think its too early to kill netfx support.
Beside from general netfx support, there are also third party tools (e.x. LinqPad) which are not yet migrated to netcore. Moving to netstandard 2.1 would basically kill linqpad support, which would be very sad.

[Edit]: I think EfCore should target netstandard 2.0 at least until .netcore 3.1. Retarget netstandard 2.1(+) when shipping with the .net core 4. / .net 5 :-)

[kevinchalet]

Any news?

FWIW, the Microsoft.Bcl.AsyncInterfaces package was pushed to NuGet: https://www.nuget.org/packages/Microsoft.Bcl.AsyncInterfaces/1.0.0-preview6.19259.10

[ajcvickers]

First, thank you all for the feedback. As always, we really appreciate it.

Let me try to clarify a few points:

• This kind of change is not something we take lightly. There have been extensive discussions around whether or not this is the right thing to do and the right time to do it. Strong arguments can be made on both sides. However, this is part of a broader strategy for all of .NET going forward, as described by Scott Hunter in his recent blog post. EF Core is a key part of that strategy and this decision for EF Core fully aligns with the overall direction for .NET, including allowing EF Core to continue to evolve and innovate in ways that are needed to move .NET forward.
• This decision is not based on the technicalities of how to implement async enumerable support on .NET Standard 2.0. Or to put it another way, we know it is technically possible to do this, and while there are technical complications that we would rather not take on, this is not the fundamental reason why we are choosing to target .NET Standard 2.1. This means that having a package available for this does not change the decision.
• Note that this change (dropping support for a target) is breaking and so cannot be done in a minor release. This is one reason why pushing this out to EF Core 3.1 is not feasible.
• We announced this decision as soon as we were able to, but we recognize that an earlier announcement would have been valuable. We will continue to try to improve in this area.

Thanks again for the feedback.

[kevinchalet]

Thanks for the reply, @ajcvickers.

This decision is not based on the technicalities of how to implement async enumerable support on .NET Standard 2.0.

I’m confused because it’s exactly the argument @divega mentioned in his recent post: https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-3-0-preview-4/. Have I missed something?

If async enumerable support is not the main motivation for abandoning .NET Standard 2.0, then can you please shed some light on why moving to 2.1-only is required?

Now that Entity Framework 6 is compatible with .NET Standard 2.1, it’s amusing to note that it will be compatible with more platforms than EF Core 3.0, which will initially only be usable on .NET Core 3.0 (UWP/.NET Native, Xamarin and Unity will likely take some time to catch up)

Should EF Core 2.x users move back to EF 6 to keep using EF in .NET Framework apps?

[davidroth]

Thanks for the answer @ajcvickers
But it is still not clear on why you are making the change now.

Can you elaborate on how EfCore 3.0 targeting netstandard2.1 aligns with the vision of net5? (Net5 is planned for fall 2020, so only ~1 year from 3.0 Core)

We announced this decision as soon as we were able to, but we recognize that an earlier announcement would have been valuable.

You could still step back and announce that EfCore 3.0 targets standard 2.1 2.0 and EfCore 4 could then target netstandard 2.2 2.1 in the 2020 timeframe.

[divega]

I’m confused because it’s exactly the argument @divega mentioned in his recent post: https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-3-0-preview-4/. Have I missed something?

@PinpointTownes That blog post reflects what our thinking was around a month ago. After that, we learned that some of the technical concerns would be addressed by Microsoft.Bcl.AsyncInterfaces and we had many more discussions, including conversations with the larger .NET team about how to best align the EF Core roadmap to the overall .NET strategy. The decision to target .NET Standard 2.1 remains the same, although the mix of reasons that contribute to it has changed significantly.

You could still step back and announce that EfCore 3.0 targets standard 2.1 and EfCore 4 will target netstandard 2.2 and everybody would be happy.

@davidroth Sorry if there has been any confusion in communications. The plan is already for EF Core 3.0 to target .NET Standard 2.1. EF Core 4.0 is too far in the future to know.

[davidroth]

@divega Sorry I was mixing up netstandard versions. I have updated my previous comment.

The decision to target .NET Standard 2.1 remains the same, although the mix of reasons that contribute to it has changed significantly.

Well then I can only hope that Linqpad transitions to netcoreapp this year. Otherwise it will be a very sad story for those relying on this tool for interactive ef core query execution. (We use it heavily).

[kevinchalet]

The decision to target .NET Standard 2.1 remains the same, although the mix of reasons that contribute to it has changed significantly.

So it's absolutely not a technical motivation - you could keep supporting .NET Standard 2.0 if you wanted to - but rather a deliberate business decision? (at least, that's the logical conclusion since you haven't mentioned any concrete point that would justify that from a technical POV).

I really hate to be that guy, but it's honestly sad to see that you haven't learnt from the past few years that a clear, firm and honest communication strategy is absolutely necessary: you can't reasonably announce you'll keep supporting .NET Framework in 3.0 and finally decide you won't, based on technical grounds that are not even justified.

I can certainly understand how hard it can be for employees of such a huge company to realize that their announcements and decisions can have a major impact on tiny structures - for which using EF Core in their .NET Framework apps may have been an important investment - but please, take some time weighing the pros and cons of your decision: keeping a netstandard2.0 TFM is probably nothing for you, but a life-saver for those who bet on EF Core.

If ditching .NET Framework is still the official plan, then make the motivations crystal clear: things like "we initially thought the lack of IAsyncEnumerable support would be blocking, then we realized it wouldn't be but we now have other reasons for that we don't even bother mentioning" are not good signals. I'm sure we deserve better.

[poke]

However, this is part of a broader strategy for all of .NET going forward, as described by Scott Hunter in his recent blog post.

[…] we had many more discussions, including conversations with the larger .NET team about how to best align the EF Core roadmap to the overall .NET strategy.

I honestly don't get how the announced future of .NET, a version 5 that releases in 2020, has any effect on Entity Framework Core 3.0. If there are no real technical reasons, you could easily stick to netstandard2.0 and upgrade to 2.1 later when you actually see a real reason to require new things.

This really feels like ASP.NET Core 2.0 again. And I'm really disappointed that you don't try harder to actually avoid breaking changes, especially those that break full scenarios and don't have a way around.

Note that this change is breaking and so cannot be done in a minor release. This is one reason why pushing this out to EF Core 3.1 is not feasible.

Then do it as a EF Core 4, or wait another few months and release it with .NET 5. EF Core isn't moving that fast to justify not being able to wait a bit longer for a target jump.

That being said, this whole idea of semantic versioning with “no breaking changes in non-minor versions” is broken anyway by the time .NET gets on a fixed release cycle that's not even considering minor releases.

Well then I can only hope that Linqpad transitions to netcoreapp this year. Otherwise it will be a very sad story for those relying on this tool for interactive ef core query execution.

There was a time where you actively reached out to community members to ensure that they would stay ahead of the challenges you put in their path, especially for popular things like Linqpad (which you ironically even used yourself). A late announcement for a major breaking change is really the exact opposite.

[kevinchalet]

I'm sure we deserve better.

Apparently, we don't 😆

[304NotModified]

Any way, this is fixed in EF Core 3.1

EF Core 3.1 reintroduces support for .NET Standard 2.0, rather than requiring .NET Standard 2.1 as was the case for EF Core 3.0