packages.lock.json broken with Sdk-Style C# project targeting net5.0-windows

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

When using a Sdk-Style C# project targeting net5.0-windows with package references it is not possible to lock the nuget packages via packages.lock.json.

The restore fails both in commandline and in visual studio.
"error NU1004: The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Disable the RestoreLockedMode MSBuild property or pass an explicit --force-evaluate option to run restore to update the lock file."

Steps to reproduce:

1. run dotnet restore --force-evaluate to create the packages.lock.json file
2. delete obj folder (or just the project.assets.json file)
3. run dotnet restore

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
    <TargetFramework>net5.0-windows</TargetFramework>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
    <RestoreLockedMode>true</RestoreLockedMode>
  </PropertyGroup>

</Project>

Error occurs whether a nuget package is installed or not. The same code works as expected when the targetframework is another framework, e.g. net5.0 or net461.

---

Original Comments

Feedback Bot on 5/20/2021, 06:43 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

---

Original Solutions

(no solutions)

[heng-liu]

I could repro with the same repro steps above.
The packages.lock.json has the following contents:

{
  "version": 1,
  "dependencies": {
    ".NETCoreApp,Version=v5.0": {
      "Newtonsoft.Json": {
        "type": "Direct",
        "requested": "[13.0.1, )",
        "resolved": "13.0.1",
        "contentHash": "ppPFpBcvxdsfUonNcvITKqLl3bqxWbDCZIzDWHzjpdAHRFfZe0Dw9HmA0+za13IdyrgJwpkDTDA9fHaxOrt20A=="
      }
    }
  }
}

However, the project.assets.json has the following contents:

{
  "version": 3,
  "targets": {
    "net5.0-windows7.0": {}
  },
  "libraries": {},
  "projectFileDependencyGroups": {
    "net5.0-windows7.0": [
      "Newtonsoft.Json >= 13.0.1"
    ]
  },

So this line found the TFMs are different, hence the restore failed.

[johnendev]

This issue makes locked-mode completely unusable when targeting net5-windows. When can we expect this to be fixed?

[heng-liu]

FYI @aortiz-msft, @nkolev92

[v-longmin]

We can repro this issue on .NET 6.0, and the packages.lock.json file is blank after restoring project.

[reduckted]

I've just encountered this problem. Using nuget.exe v5.10.0-preview.2, the error message says:

NU1004: The project target framework net5.0-windows7.0 was not found in the lock file. The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Disable the RestoreLockedMode MSBuild property or pass an explicit --force-evaluate option to run restore to update the lock file.

[nkolev92]

Bug likely here: https://github.com/NuGet/NuGet.Client/blob/229fe85a271e9c059d14849d6e9fcc833e61809c/src/NuGet.Core/NuGet.ProjectModel/ProjectLockFile/PackagesLockFileTarget.cs#L34, needs to be equivalent to https://github.com/NuGet/NuGet.Client/blob/229fe85a271e9c059d14849d6e9fcc833e61809c/src/NuGet.Core/NuGet.ProjectModel/LockFile/LockFileTarget.cs#L18

[mungojam]

As a workaround, try setting TargetFramework to:

<TargetFramework>net5.0-windows7.0</TargetFramework>

taken from dotnet/sdk#14553 although I don't know for sure if the two issues are related

[aortiz-msft]

Fix is currently targeting .NET 6 Preview 7.

[reduckted]

@aortiz-msft Will this be back-ported to .NET 5?

[aortiz-msft]

@reduckted @johnendev - Have you had a chance to try .NET 6 Preview 7 (or Visual Studio 2022 Preview 3) and confirm that the issue is fixed there? We backport fixes based on impact, so please thumbs up the previous comment if you'd like the fix backported to .NET 5.

[reduckted]

Thanks @aortiz-msft. 😄 I've just tried using the .NET SDK 6 preview (specifically 6.0.100-preview.7.21379.14), and it does fix the problem for me. Unfortunately, I don't think using the preview SDK is an option for me at the moment, so back-porting the fix would be much appreciated.