-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
EF Core 3.1 to target .NET Standard 2.0 #18141
Comments
https://docs.microsoft.com/en-us/dotnet/standard/net-standard 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. |
@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. |
Duplicate of #15498 |
Sorry, missed that other issue. |
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. |
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. |
Also using EF Core but can't upgrade as I'm using it in UWP apps that only support .net standard 2. 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 |
@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? |
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. |
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... |
@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. |
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) |
Assigning this to @bricelam in 3.1 to prototype and validate. This is not yet a commitment that we will do this. |
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: 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: -- Cited reasons for this path forward seem to be related to risk/effort involved. So here we are! |
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. |
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. |
@bricelam that's excellent news! I'm really glad we came to the same conclusion 😄 Quick question: have you considered keeping the
|
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. |
Makes sense, I guess. Still, cross-targeting would be useful to simplify the dependencies graph, and it doesn't require adding ifdefs. |
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 |
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 |
Thanks for retargeting .NET Standard 2.0! This saves my UWP app from EFCore 3.0 Preview 5. |
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. dotnet ef dbcontext scaffold See more : |
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
The text was updated successfully, but these errors were encountered: