EF Core 3.1 to target .NET Standard 2.0

[OpenSpacesAndPlaces]

Update from 2.1.4 to 3.0.0

Could not install package 'Microsoft.EntityFrameworkCore 3.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.8', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Steps to reproduce

Update to Microsoft.EntityFrameworkCore 3.0.0 via Visual Studio 2019 Nuget
Further technical details

EF Core version: 2.1.4 -> 3.0.0
Database provider: (e.g. Microsoft.EntityFrameworkCore.SqlServer)
Target framework: .Net Framework 4.8
IDE: Visual Studio 2019

ref: #17999

EF Core 3 to target .NET Standard 2.0 so .Net Framework continues to be supported

[daniel-white]

https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/breaking-changes#netstandard21

[OpenSpacesAndPlaces]

https://docs.microsoft.com/en-us/dotnet/standard/net-standard
"The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations. The motivation behind the .NET Standard is establishing greater uniformity in the .NET ecosystem. "

I'm well aware that it was dropped - I was encouraged by another contributor to open up a feature request for this.

IMO the move seems antithetical to why .Net Standard was created.

[roji]

@OpenSpacesAndPlaces you can read the discussion in #15498. In any case, the decision has already been made, and new versions of EF Core will definitely not be targeting .NET Framework again.

[roji]

Duplicate of #15498

[ErikEJ]

@roji not so fast, @bricelam asked the OP to create an issue, afaik

[roji]

Sorry, missed that other issue.

[smitpatel]

Whoever is stumbling upon this thread, if you require EF Core 3 to target netstandard2.0 then please upvote first post.

[IanKemp]

Whoever is stumbling upon this thread, if you require EF Core 3 to target netstandard2.0 then please upvote first post.

Or... just stay on EF Core 2.2. 🤷‍♂ The fact that there is no version of the .NET Framework that implements .NET Standard 2.1 is not the EF Core team's problem, nor should it be.

[daniel-white]

1000% @IanKemp. the orignal decisions to support ef core 1 and 2 on .net framework was a bonus. the writing was on the wall for .net framework. it sounds like there won't even be a .net standard for .net 5.

[Pinox]

Also using EF Core but can't upgrade as I'm using it in UWP apps that only support .net standard 2.
Reading between the lines I understand the UWP team is working on a solution to support .net core 3.0 in near future.

If this support for .net core 3 in UWP and .net standard 2.1 takes 6 months to complete then this request would be reasonable from users as it also allows UWP apps to use EF Core 3

[bricelam]

@Pinox +1 This is also about UWP and Unity which tend to take longer to catch up to .NET Standard. But the question then becomes, will they catch up sooner than we could release a version targeting .NET Standard 2.0?

[bricelam]

It's also worth noting that there is a serious downside to us targeting .NET Standard 2.0: Using C# 8 is unsupported. We couldn't take advantage of things like default interface members when evolving EF Core.

I feel like even if we did go back to .NET Standard 2.0 in EF Core 3.1, we'd just drop it again in the version after that. But maybe having one more LTS release on .NET Standard 2.0 is enough to satisfy those asking for this.

[roji]

Just to say that although officially unsupported, C# 8 does work just fine :) Npgsql multitargets to .NET Framework and there really aren't any issues. Except for default interface members which require runtime support...

[Pinox]

@bricelam Cannot agree more with your statement. One last thing worth noting is if UWP eventually supports .net standard 2.1 it would probably need the 20H1 Windows 10 minimum version for all users and that would not be cool at all as you then kick the ball down the road for another year before you can start using the latest tech. (in this case waiting for users to catch up)

One last LTS on .net standard 2 will just help level the playing fields for all the different platforms to catch up even though it will be dropped again after that. At least then when support is dropped all the different platforms will support .net standard 2.1 and most users should be on a Windows 10 version that support .net standard 2.1 in the store.

[jwooley]

For me the advantage would be to work with Winforms which need to have multi targeting with 4.8 and 3.0 until such time the designers get full support for 3.0 native experiences. That means we're limited to EF 2.2 until the WinForm designers catch up. (Likely quite a bit after 3.1)

[ajcvickers]

Assigning this to @bricelam in 3.1 to prototype and validate. This is not yet a commitment that we will do this.

[OpenSpacesAndPlaces]

IMO, as above, where this fell off was that .Net Standard 2.1 was dropped from .Net Framework.

The way I always read about .Net Standard, and the way it was presented at conferences, was as the mission statement from the page still reads:
"The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations. The motivation behind the .NET Standard is establishing greater uniformity in the .NET ecosystem. "
https://docs.microsoft.com/en-us/dotnet/standard/net-standard

---

With the drop of support for .Net Standard 2.1 on .Net Framework, individual projects are now on the front-lines of what to-do with that outcome.

Per their own statement:
"Library authors who need to support .NET Framework customers should stay on .NET Standard 2.0. In fact, most libraries should be able to stay on .NET Standard 2.0, as the API additions are largely for advanced scenarios. However, this doesn’t mean that library authors cannot take advantage of these APIs even if they have to support .NET Framework. In those cases they can use multi-targeting to compile for both .NET Standard 2.0 as well as .NET Standard 2.1. This allows writing code that can expose more features or provide a more efficient implementation on runtimes that support .NET Standard 2.1 while not giving up on the bigger reach that .NET Standard 2.0 offers."
https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/

--

Cited reasons for this path forward seem to be related to risk/effort involved.

So here we are!

[bricelam]

The feedback from you and others is that EF Core made the jump to .NET Standard 2.1 too soon. A lot of apps are still transitioning to .NET Core, and the ecosystem of libraries (especially WinForms and WPF) is also still translationing. Even UWP and Unity aren’t ready for .NET Standard 2.1 yet.

After investigating this, we discovered that a lot more of corefx has been backported to .NET Standard 2.0 than we originally anticipated when we made the decision to target .NET Standard 2.1.

Given your feedback and the unexpectedly low cost of maintenance--remember, we're just a small team of five engineers--we decided it was probably worth implement this.

We hope that one last LTS release on .NET Standard 2.0 will give everyone a chance to catch up to the vision of .NET 5.

[bricelam]

Also, our decision to reduce breaking changes in future major versions (see #18256 (comment)) will help support transitioning apps. If it does take apps a while to migrate off of .NET Framework, upgrading to the latest version of EF Core when you finally do should be a lot less jarring than it has been in the past.

[kevinchalet]

@bricelam that's excellent news! I'm really glad we came to the same conclusion 😄

Quick question: have you considered keeping the netstandard2.1 TFM (instead of replacing it by netstandard2.0)? I'm asking that because it would have two advantages:

• The dependencies graph would be reduced on netstandard2.1, as you wouldn't need the 2 BCL compat' packages. The Microsoft.Extensions.* packages that use IAsyncEnumerable all do that for this reason.

• Platforms supporting netstandard2.1 could use newer API without using reflection (like the new ValueTask-based methods on DbConnection).

[bricelam]

We considered it, but the cost of maintenance is higher than we'd like. Using #if is ugly and knowing when you can and can't use certain features just adds complexity. We'd also like to keep the cost of fixing bugs and merging them back to newer branches as minimal as possible.

[kevinchalet]

Makes sense, I guess. Still, cross-targeting would be useful to simplify the dependencies graph, and it doesn't require adding ifdefs.

[bricelam]

I was curious so I measured it. The two new packages are the only ones introduced to the graph on .NET Standard 2.1/.NET Core 3.1.

Extra restore size (once per machine): 0.17 MB
Extra deploy size (once per app): 0.03 MB

[kevinchalet]

I agree there's no huge gain to expect from cross-targeting, but for the .Extensions packages, extreme care was taken to ensure these packages were not unnecessarily referenced (for more context: dotnet/extensions#2137), which is why I suggested that (well, at least for consistency).

/cc @davidfowl

[KexyBiscuit]

Thanks for retargeting .NET Standard 2.0! This saves my UWP app from EFCore 3.0 Preview 5.

[abdelgrib]

Worked for me !

You cannot target directly .NET Standard dll bt scaffold ! Specify the exe project (start-up) of the solution that ref your dll in your scaffold script.
Add the necessary packages to your exe project.

dotnet ef dbcontext scaffold
"conn_string"
Npgsql.EntityFrameworkCore.PostgreSQL
-o Entities
-project <target_project> //or -p <target_project> or us cd to this project
--startup-project ../<exe_project_name> //or -s ../<exe_project_name>

See more :

https://stackoverflow.com/questions/48673987/trying-to-set-up-entity-framework-core-in-net-standard-project