Forced locked mode doesn't work cross platform

[jabbera]

Details about Problem

When running a dotnet restore --locked-mode from a linux environment where dotnet restore --force-evaluate was run on windows it fails. This makes things very difficult to test cross platform. (Build on a linux agent then run tests on windows). Note: it happens either way (lockfile generate on linux causes windows to fail)

NuGet product used: dotnet.exe

NuGet version (x.x.x.xxx):

❯ dotnet nuget --version
NuGet Command Line
5.4.0.2

dotnet.exe --version (if appropriate):

❯ dotnet --version
3.1.102

OS version (i.e. win10 v1607 (14393.321)): Windows 10 Enterprise: 10.0.18363 and Ubuntu 18..04 (WSL in my case, but repro's on build agents as well)

Worked before? If so, with which NuGet version: Unknown

Detailed repro steps so we can see the same problem

1. git clone https://github.com/jabbera/nuget-locked-mode-bug.git
2. cd nuget-locked-mode-bug
3. dotnet restore --locked-mode # This succeeds as it should
4. bash
5. dotnet restore --locked-mode # This fails with:error NU1004: The packages lock file is inconsistent with
6. dotnet restore --force-evaluate
7. exit
8. git diff # This will let you see the differences between the OS's

Other suggested things

Output of the diff:

diff --git a/packages.lock.json b/packages.lock.json
index 1d02123..d72a20f 100644
--- a/packages.lock.json
+++ b/packages.lock.json
@@ -9,7 +9,6 @@
         "contentHash": "7D2TMufjGiowmt0E941kVoTIS+GTNzaPopuzM1/1LSaJAdJdBrVP0SkZW7AgDd0a2U1DjsIeaKG1wxGVBNLDMw=="             }
     },
-    ".NETCoreApp,Version=v3.1/win7-x86": {},
     ".NETFramework,Version=v4.6.2": {
       "Microsoft.NETFramework.ReferenceAssemblies": {
         "type": "Direct",
@@ -25,7 +24,6 @@
         "resolved": "1.0.0",
         "contentHash": "ONGjkFWduK13lfxUtlEl4+nYwrqDe5NF5f8qRtp5fqWiWYlqft/Ko9ht3e6Secg9y3I1yL8Xnfag/JGOOn0yoQ=="             }
-    },
-    ".NETFramework,Version=v4.6.2/win7-x86": {}
+    }
   }
 }
\ No newline at end of file

[jabbera]

Hi! Is there any chance of this getting prioritized? Just trying to plan.

[wocar]

is this ever going to happen?

[jabbera]

I've given up.

[kartheekp-ms]

I can reproduce this issue on .NET Core Console App that multi-targets net472 and a .NET core tfm. I cannot reproduce this issue on a .NET Core Class Library project with multiple target frameworks.

@nkolev92 helped me to find that .NET SDK sets runtime identifier to win7-86 here. It looks like following comment in the .targets file confirms this behavior.

When building a .NETFramework exe on Windows and not given a RID, we'll pick either win7-x64 or win7-x86

Transferring to dotnet/SDK team for feedback.