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

[bricelam]

😏

[basecde]

Great to see .NET Standard 2.0 added back here, but I'm slightly concerned by the strategy driving decisions around this.

Most forward thinking .NET devs are hugely supportive of the direction .NET Core (and EF Core) is going. The pace and momentum that you guys at Microsoft have at the moment is outstanding.

However, there is a certain speed of change and churn, that if reached, will end up leaving large chunks of the .NET audience behind, despite best intentions on all sides - I'm thinking enterprise teams and any team with a large migration task on their hands.

.NET teams worldwide are at a juncture here where they need to decide whether to switch their project to legacy/maintenance mode - because its too big to migrate and lets face it Framework is a dead (ok, stagnating) platform, however you dress it up, or whether to migrate.

The teams that are migrating, have to do this work quickly or the bridges will be burned by the time they get there.

In my team, with a monolithic ASP.NET Webforms app, we've moved up to 4.8 and then have started migration to .NET Standard 2 and from EF to EF Core. I consider us ahead of the curve when looking at monolithic/enterprise projects. Outside of the Microsoft bubble, a lot of dev teams are only just getting to grips with moving to Core. The stability has not been there very long.

The release of EF Core 3 without .Net Standard 2.0 was akin to the bridge collapsing just as we reached it. We are (were) faced with having to migrate BACK to EF which although the older library, has better forward support than EF Core at the time of writing. Oops.

To me, (albeit with a sample size of 1) this is a sign that your pace of forward movement and bridge burning is right at the upper limit of what is going to be acceptable and feasible for the general population to keep up with. I implore you not to out-run everyone - it will have detrimental effect on the whole ecosystem. (I say this referring to both EF Core and .NET Core as a whole).

The health of .NET relies both on this massive forward momentum that teams like yours have achieved, and leaving enough of a breadcrumb trail for those still in the legacy Framework world to follow. Without sufficient consideration of the latter you're going to loose a lot of people.

That said, thank you very much for listening to the comments on this issue and for merging this PR!

[IanKemp]

.NET teams worldwide are at a juncture here where they need to decide whether to switch their project to legacy/maintenance mode - because its too big to migrate and lets face it Framework is a dead (ok, stagnating) platform, however you dress it up, or whether to migrate.

If your project has no UI, migrating is easy (depending on your dependencies).

If your project is WinForms, classic ASP, or ASP.NET MVC 5, migrate the data access and domain code, to a new project and then throw the old UI part away and redo it from scratch. If you try to migrate the UI portion, you are on a road of pain and madness and the end result will be something that Microsoft stops supporting in a few years' time anyway. If your business isn't willing to give you time to do this, don't bother migrating to Core.

Personally, I wouldn't recommend migrating anything. Start new projects in Core and upgrade as new versions come along, accept that current Framework projects are legacy and make plans to sunset them, and you will be much happier.

We are (were) faced with having to migrate BACK to EF which although the older library, has better forward support than EF Core at the time of writing.

... what?

You do realise there's versions of EF Core prior to 3.0, right?

You do realise that .NET Core 3.0 supports .NET Standard 2.1, and therefore there's no good reason for anything that's targeted at Core 3.0 (like, say, EF Core 3.0) to support any earlier version of Standard, right?

I'm sure the EF Core team is going to claim that EF versions are not tied to Core versions but let's be honest - there's a very particular reason they branded this release 3.0.0 and not 2.3.0. The messaging from Microsoft here is clear as day: if you want the latest versions of components that depend on Core, you have to be on the latest version of Core. Simple and unambiguous, yet why do so many people not get it?

And why has the EF Core team now decided to create a scenario where EF Core 3.0.0 requires .NET Standard 2.1, but 3.1.0 will only require Standard 2.0, and then 3.2.0 and onward will require Standard 2.1 again? It's bloody bonkers, and it certainly won't stop people crying about not being able to upgrade because the third-party frameworks they use haven't yet put in the effort to support Core 3.0, despite it being in preview for an entire year.

So... yeah. I appreciate this is a relatively small change, and it makes people who are behind the curve feel warm and fuzzy inside, but I honestly don't see the point.

[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 https://github.com/aspnet/EntityFrameworkCore/issues/18256#issuecomment-540109273) 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: https://github.com/aspnet/Extensions/pull/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 //or -p or us cd to this project
--startup-project ../ //or -s ../

See more :

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