NU1202 Package Framework Compatiblity Error Emitted on Precisely Compatible Framework (Windows Only?)

[gilmorem560]

NuGet Product Used

dotnet.exe, Visual Studio Package Management UI

Product Version

dotnet CLI 8.0.204 (Windows), Nuget Package Manager 6.9.2

Worked before?

dotnet CLI 8.0.204 (macOS)

Impact

It's more difficult to complete my work

Repro Steps & Context

dotnet new classlib -f net6.0
dotnet add package Microsoft.EntityFrameworkCore -v 6.0.7

Found today trying to load a project I'm working on using .NET 6 that a package which here clearly states it is compatible with net6.0 (and we have indeed had in a few net6.0 projects for a long time) is now not compatible with net6.0: https://www.nuget.org/packages/Microsoft.EntityFrameworkCore/6.0.7#supportedframeworks-body-tab

For the record, the latest 6.0.x version does restore, as do the 6.0.6 and 6.0.8 versions right around this one. Additionally, doing this very same, with the same version of the dotnet CLI tool actually does work on macOS. Thus far this appears to strictly be happening with package version 6.0.7 of this package on Windows.

I don't have a means at present to contact the package authors but I wanted to get this visible to folks here as everything on the published package that I can see indicates net6.0 should be very much supported.

For the record both the link above and the NuGet Package Manager in Visual Studio display net6.0 as the compatible framework for this package:

Upgrading package is fine in my personal use case, but still this seems pretty contradictory and may indicate some deeper issue. I want to make sure I document this in case anyone else runs into this sort of problem where the package add/restore operation directly contradicts the package metadata on Windows.

Verbose Logs

error: NU1202: Package Microsoft.EntityFrameworkCore 6.0.7 is not compatible with net6.0 (.NETCoreApp,Version=v6.0). Package Microsoft.EntityFrameworkCore 6.0.7 does not support any target frameworks.

[nkolev92]

Is this happening on a single machine @gilmorem560?

I'm wondering if somehow the package installed got messed up.

[gilmorem560]

I've pulled the application I'm having trouble with down on a few separate occasions this past week and each time I've run back into this snag. I've tried clearing the NuGet cache on my machine to no avail. I'm starting to think this might not be worth tying up your resources with because it is happening in such a narrow environment, and this next week my org is moving that one project to .NET 8 anyway.

Anywho, what could provide some insight is if there is a way when querying the NuGet package via the CLI utility to "ask" precisely which framework versions the utility sees that it expects for the package. Somewhere one side is saying "I'm net6.0" and another side is saying "net6.0" is not in the valid frameworks, so I suspect visibility into precisely what the CLI thinks are valid frameworks may bear fruit. That said, I tried various verbose options with the package listing features and while I could get lists of versions of the packages in CLI, I couldn't find any such lookup/verbose option to list what, at that time of execution, it is reporting as the valid frameworks.

Is there any such option? Something akin to

dotnet package search Microsoft.EntityFrameworkCore --exact-match

That would spit back something to the effect of "supported framework(s)"?

[nkolev92]

There's no end user aimed way of doing that, but the project.assets.json would allow us to figure it out.
Compat is 99% folder sctructure, and the assets file will contain a list of files it's considering.

If you're still willing to pursue this please follow:

dotnet new classlib -f net6.0
dotnet add package Microsoft.EntityFrameworkCore -v 6.0.7 --no-restore
dotnet restore

and upload the project.assets.json from the project's obj directory.

I was not able to repro this on my machine.

If you'd prefer not to continue, you can just close the issue.

[gilmorem560]

Well generating that log finally helped me find the errant copy of the package. I guess clearing the cache from the command-line didn't hit every single location a copy of the package could've been stored. After generating it, I checked all of the package folders listed under packageFolders as well as project.fallbackFolders and project.packagesPath. I finally found an offending package at C:\Program Files\dotnet\sdk\NuGetFallbackFolder.

For the record what I had done previously to try and eliminate this possibility was:

dotnet nuget locals all --clear

As I was starting to suspect, seems to be a bad copy of a package on my machine, just in a place cache clearing doesn't touch.

So my takeaway is that NuGetFallbackFolder directory can also possibly host botched package entries that would prevent a full round-trip to a package source, and clearing the cache is not enough to also knock out potential bad entries in that underlying path.

Thanks for tossing me some breadcrumbs to find the answer. I'll share this info with my team so if we ever run into this sort of thing again we'll know where to really look to figure out where a bad copy of a package might be getting pulled in from.

Let me know if you've got any questions for me, otherwise I think this can be chalked up to not enough user research :)

[nkolev92]

As I was starting to suspect, seems to be a bad copy of a package on my machine, just in a place cache clearing doesn't touch.

NuGetFallbackFolder is something technically built on top of NuGet, and something that doesn't get installed with the .NET SDK anymore (it was removed in .NET SDK 3.0.1xx)

I think if you just delete that, you should no longer hit any problems.

I'll close this issue, but happy to keep engaging if you need more help.