Installing EF Core on a .Net Core 3.1 Project?

Is it expected and intentional that installing efcore on .Net Core 3.1 project has been broken since the release of efcore version 6?

Steps to reproduce

> mkdir new-project && cd new-project && dotnet new console -f netcoreapp3.1 && dotnet add package Microsoft.EntityFrameworkCore.SqlServer
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on C:\Users\lhard\source\repos\new-project\new-project.csproj...
  Determining projects to restore...
  Restored C:\Users\lhard\source\repos\new-project\new-project.csproj (in 50 ms).
Restore succeeded.

  Determining projects to restore...
  Writing C:\Users\lhard\AppData\Local\Temp\tmpBC20.tmp
info : Adding PackageReference for package 'Microsoft.EntityFrameworkCore.SqlServer' into project '...\new-project\new-project.csproj'.
info :   CACHE https://api.nuget.org/v3/registration5-gz-semver2/microsoft.entityframeworkcore.sqlserver/index.json
info :   GET https://nugetized.blob.core.windows.net/skiasharp-eap/registration/microsoft.entityframeworkcore.sqlserver/index.json
info :   NotFound https://nugetized.blob.core.windows.net/skiasharp-eap/registration/microsoft.entityframeworkcore.sqlserver/index.json 502ms
info : Restoring packages for ...\new-project\new-project.csproj...
error: NU1202: Package Microsoft.EntityFrameworkCore.SqlServer 6.0.0 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package Microsoft.EntityFrameworkCore.SqlServer 6.0.0 supports: net6.0 (.NETCoreApp,Version=v6.0)
error: Package 'Microsoft.EntityFrameworkCore.SqlServer' is incompatible with 'all' frameworks in project 'C:\Users\lhard\source\repos\new-project\new-project.csproj'.

FWIW, I have the .Net 3.1, 5 and 6 SDKs installed:

> dotnet --list-sdks
3.1.415 [C:\Program Files\dotnet\sdk]
5.0.403 [C:\Program Files\dotnet\sdk]
6.0.100 [C:\Program Files\dotnet\sdk]

I’ve checked https://docs.microsoft.com/en-us/ef/core/get-started/overview/install and the above package installation command is what’s recommended, but it doesn’t specify which targeted .Net Core versions that should work with.

I’ve checked https://docs.microsoft.com/en-us/ef/core/miscellaneous/platforms and it seems that version 5 is still supported, but perhaps that’s incorrect since it also lacks mention of version 6 entirely.

[roji]

Strange then how what I’m expecting is exactly what’s described as the way nuget works:

You’re mis-reading the intended purpose of that mechanism.

It’s indeed possible for the same nupkg to contain different assembly versions for different TFMs, and that indeed allows supporting older TFMs where there are slight differences that can be worked around with conditional compilation. For example, a new version of a library may want to provide an API that can only works on net6.0, e.g. because it relies on a type that has only been introduced in that TFM. That API can be compiled conditionally (#if NET6_0_OR_GREATER), and so the nupkg can contain one assembly targeting net6.0 with that API, and another targeting net5.0 without it.

That is worlds apart from including 2 completely different major versions of the same product in the same nupkg - no serious .NET library does this as far as I’m aware. There’s a very strong (and IMO justified) expectation for the same nuget version to always contain the same product version.

In this world you describe where EF core 3.1 is supported and patched, how do you expect people to keep up with those patches?

The traditional .NET package management is indeed manual - at some point before a release, you check if your dependencies are up to date and update them (tools such as dotnet outdated can help streamline that, if not automate it). Note that even when dependabot is used, there’s still the manual gesture of approving and merging the PRs submitted by the bot; you can simply manually reject dependabot PRs which are incompatible with your TFM (those would fail your CI build anyway). This isn’t a perfect solution, but it really doesn’t seem like a huge problem either.

I suspect that dependabot was written with scenarios in mind where the project always wants to on the latest dependencies - including with the .NET version used. After all, everything works well as long as you’re on the latest TFM. As I wrote above, I do think the problem you’re describing exists and should be addressed - it should be possible to use dependabot to update dependencies to the latest version which supports your TFM. That’s the right fix here, rather than packing multiple major versions into the same nuget.

I’m done trying to convince you. Hopefully others pick it up from here because EF Core is an important package, and those using it don’t deserve this pain.

Once again, understand that you’re trying to argue something against the entire .NET ecosystem - this conversation has nothing to do with EF Core. And while mixing versions inside a nuget would work around the specific problem you have - which really doesn’t seem all that critical - you seem to be ignoring all the downsides and complications it would introduce.

[roji]

Welp, we differ. To me any manual intervention in a patching process is simply a non-starter. My commitment to customers is always applying security patches in a timely manner, and that means full automation.

Have you raised this with dependabot and/or nukeeper? If it’s handled on their end, that fixes things for the entire ecosystem, whereas what you’re proposing would have to be done for each and every package (EF Core is just one package).

Is there any reason you’re insisting that this is an EF Core problem and not a dependabot problem?

A little difficulty/distaste on the part of package authors is entirely worth it to keeping the package consumer’s life simple, and secure by default.

You may not have fully thought about the consequences of what you’re proposing. If you mix different EF Core versions in the same nuget package, it becomes extremely difficult to answer the question “which version of EF Core am I using”. The nuget version becomes meaningless, and the only way to know what’s being used is to locate the assembly for the given TFM within the nupkg, open it and examine the [AssemblyVersion] attribute inside, or similar. In fact, what the “given TFM” is isn’t trivial either, as your consuming application (or library) may itself be multitargeting - if that happens, your own code may need to interact differently with EF Core, as it’s using different major versions when targeting different TFMs.

This is, quite simply, an unworkable state of affairs.

If EF Core 6 was so radically different than 3 or 5 that it couldn’t be in the same package, then it should have been a new package. Or, maybe you could have created a package for the 3.1 and 5 versions, and documented that path for “legacy” (but still supported) projects. Either would have been better than the current situation IMHO.

It’s easy to make assertions like this, but the reality of the world of software simply doesn’t work like that. EF Core is different than 3 or 5; I wouldn’t use the word “radically”, but these are three major versions which differ behaviorally, and may very well include breaking changes (remember, major versions may contain those). Asking us to have a new package name every time a breaking change is introduced just doesn’t make sense.