LockFile with ATF has false NU1004 due to a bad target framework equality check

[nkolev92]

Motivation from #7889 (comment).

https://github.com/NuGet/NuGet.Client/blob/057f2ed60c19832413bac010990905a3b9577d67/src/NuGet.Core/NuGet.ProjectModel/ProjectLockFile/PackagesLockFileUtilities.cs#L123

The root cause is that the framework in TargetFrameworkInformation is ATF based.
https://github.com/NuGet/NuGet.Client/blob/057f2ed60c19832413bac010990905a3b9577d67/src/NuGet.Core/NuGet.ProjectModel/PackageSpec.cs#L92
but the one in https://github.com/NuGet/NuGet.Client/blob/057f2ed60c19832413bac010990905a3b9577d67/src/NuGet.Core/NuGet.ProjectModel/ProjectRestoreMetadata.cs#L75 is not.

[nkolev92]

Note that this could be intentional as one of the models is used for Package and the other one for Project references.

Need to understand that before making any sort of change.

[nkolev92]

The investigation as to why one of the models has ATF but the other doesn't can be handled separately.
This specific scenario is not affected since GetNearest will only consider the root framework.

FallbackFramework is a different concern however, but it's broken by design and it should not be used, so it might be to let that one be.

[nkolev92]

Initial work is in dev-nkolev92-lockFileATF.

[bergbria]

It's worth noting that this is a significant regression that will probably break most people who use lock files.

@nkolev92 - how long would you guess it will take to release a patched .net sdk version once you make the fix? My team is effectively blocked from updating to 2.2.300+ until then.

[nkolev92]

I don't know if this is going to go in a patch release.
There were other issues fixed that customers would've been likely to hit. (most of them affect the lock file regeneration scenarios).

//cc @rrelyea can comment on that.

[rrelyea]

@bergbria - what sdk version are you on now?
Regresssion in 2.2.300??
Would waiting for 2.2.400 be unacceptable?

[bergbria]

@rrelyea - sorry, my original comment listed the sdk version but I didn't mirror that here.

AFAIK, the issue was introduced in 2.2.300. I know for a fact it didn't exist in 2.2.103 but I haven't tried the intervening versions.

How long until 2.2.400 is released?

We have no raging fires that can only be extinguished by taking a new sdk version. The most impactful issue is the one linked to this thread (the name of the .csproj must match the assemblyname) and there are various quality-of-life fixes (like not spewing tons of spurious warnings when using a lock file).

Effectively, we want a number of fixes and have been waiting quite a while, but we can keep waiting if needed.

[nkolev92]

@bergbria 2.2.400 will be out in early to mid July.

[nkolev92]

@bergbria Any other lock file specific fix that you are blocked on, or have we covered the bases already?

[bergbria]

@nkolev92 - I don't think I have any other unresolved lock-file-centric issues at this time.

Thanks for the fix! Any chance of this making it into a patch release or do we need to wait for 2.2.400?

[bergbria]

@rrelyea / @nkolev92 - ping on whether there's any chance of a patch version or if we'll need to wait another month for 2.2.400.

[rrelyea]

shipping a patch version of nuget.exe is all within our teams control. dotnet sdk patch versions aren't totally within our control.
if we shipped a patch nuget.exe, would that be usable for you? or do you only use dotnet.exe?

[daniel-white]

is this going to land in 2.1? i'd appreciate a fix there.

[nkolev92]

Per https://docs.microsoft.com/en-us/nuget/release-notes/nuget-5.2-rtm, it's available in 2.1.800

[daniel-white]

@nkolev92 thanks!