Home: [Test Failure][Repeatable Restore] Error NU1403 occurs when enabling ‘RestorePackagesWithLockFile’ after installing PR packages into.NET Core project

Created on 23 Oct 2018  ·  13Comments  ·  Source: NuGet/Home

Details about Problem

NuGet version: NuGet Client Release-4.9.0-preview5\4.9.0.5627
VS Version: D15.9\28219.56
OS Version: Windows 10 RS4_Release 17134.1.180410-1804

Detailed repro steps

  1. Create a C# Console Application (.NET Core) project via VS.
  2. Install a few ‘PackageReference’ packages into the project.
  3. Set MSBuild property “RestorePackagesWithLockFile” to true in csproj file.
  4. Cd to the solution and run command “donet restore”.

    Expected

No error occur.

Actual

Error “NU1403: The package Microsoft.NETCore.App.2.1.0 sha512 validation failed” show as below screenshot.
bug7427

Note

  1. It doesn’t repro when skipping step 3.
  2. It doesn’t repro when restoring through PM UI in step 4.
Restore NotRepro PackageReference

Most helpful comment

Is there a reliable solution for this? I am running NuGet 5.0.0.6, I've cleared all caches and fallback folders multiple times, and I'm still unable to get a CI build to pass without this error.

All 13 comments

Github failed to attache screenshot today. Will update the screenshot later.

The "packages.lock.json" file updated correctly. Only the error is not expected.

was the packages.lock.json already exists when you ran dotnet restore? What was the content of before and after packages.lock.json file?

Most likely this seems to be related to this package Microsoft.NETCore.App.2.1.0 being different in fallback folder vs global packages folder (from nuget.org)

The packages.lock.json already exists before I ran “dotnet restore”.

The content of command prompt before doing step3:
C:Users\v-luzh\source\repos\ConsoleApp2\ConsoleApp2>dotnet restore
Restoring packages for C:Users\v-luzh\source\repos\ConsoleApp2\ConsoleApp2\ConsoleApp2.csproj...
Generating MSBuild file C:Users\v-luzh\source\repos\ConsoleApp2\ConsoleApp2\obj\ConsoleApp2.csproj.nuget.g.props.
Restore completed in 216.77 ms for C:Users\v-luzh\source\repos\ConsoleApp2\ConsoleApp2\ConsoleApp2.csproj.

The content of command prompt after doing step3:
C:Users\v-luzh\source\repos\ConsoleApp1\ConsoleApp1>dotnet restore
Restoring packages for C:Users\v-luzh\source\repos\ConsoleApp1\ConsoleApp1\ConsoleApp1.csproj...
C:Users\v-luzh\source\repos\ConsoleApp1\ConsoleApp1\ConsoleApp1.csproj : error NU1403: The package Microsoft.NETCore.App.2.1.0 sha512 validation failed. The package is different than the last restore.
Restore failed in 227.14 ms for C:Users\v-luzh\source\repos\ConsoleApp1\ConsoleApp1\ConsoleApp1.csproj.

Fixed on both D15.9\28230.53+NuGet Client Release-4.9.0-preview5\4.9.0.5640 and D16.0\28230.56 + NuGet Client Dev\5.0.0.5638.

I get the same, or similar behavior with different packages. But I believe it has nothing to do with the packages being PR packages as the title suggests. I get the same behavior with stable packages.
In my case, I can clear all the caches using dotnet nuget locals all --clear and run dotnet restore again. This will fix it for a while, but will get back eventually. It's difficult to track down exact repro steps in my case. But I will try again.

dotnet nuget --version reveals 4.9.0.6

Closing it as not repro on latest builds as confirmed by v-luzh

@philippdolder please log a separate issue with repro steps and complete details about your scenario.

@jainaashish can you explain what you mean by:

Most likely this seems to be related to this package Microsoft.NETCore.App.2.1.0 being different in fallback folder vs global packages folder (from nuget.org)

sometimes same package (id and version) is different in dotnet fallback folder (C:\Program Files\dotnet\sdk\NuGetFallbackFolder) and configured NuGet feed like NuGet.org which brings packages to global packages folder (%userprofile%\.nuget\packages) which will result into failure of package SHA validation at the restore time. This happens because dotnet has its own tool to generate these packages in fallback folder which is sometime different than actual package.

So the solution in that case is to delete the problematic package from dotnet fallback folder, in that case it will just download the package into global packages folder and consume that.

Is there a reliable solution for this? I am running NuGet 5.0.0.6, I've cleared all caches and fallback folders multiple times, and I'm still unable to get a CI build to pass without this error.

@Flavien not sure if you've already tried this, but we've found this issue to be very persistent even after updating it. The following usually fixes:

// first, delete all package lock files
nuget update -self 
nuget locals all -clear
nuget restore [solution]

Thanks @madelson but unfortunately, this doesn't resolve the issue.

I'm experiencing similar behavior as @Flavien

In my case it's NuGet Version: 5.0.2.5988 and Microsoft.NETCore.App.2.2.0 and our feed is on a network share.

Clearing all caches including the global packages cache and the fallback folder doesn't help.

Was this page helpful?
0 / 5 - 0 ratings