Packages.lock.json different hashes on different machines

[erik-kallen]

We have a very simple project, whose content looks like

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

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
    <RestoreLockedMode>true</RestoreLockedMode>
  </PropertyGroup>


  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />
    <PackageReference Include="Newtonsoft.Json" Version="12.0.2" />
    <PackageReference Include="Serilog.AspNetCore" Version="3.0.0" />
  </ItemGroup>
</Project>

As seen in the project, we have enabled a lock file.

Now to the problem: We have two machines, and neither of them can restore using the package.lock.json generated by the other due to content hash differences. When running dotnet restore --force-evaluate Machine A produces:

...
  "runtime.native.System.IO.Compression": {
    "type": "Transitive",
    "resolved": "4.3.0",
    "contentHash": "b+V9JC/Ii3sR659flBeaBJww111425tgjcDS1k+hqV4sGh9FALRDBvJnDtQ895gAzpPTUOFDHdqaZ2Et7BpZMg==",
...
  "runtime.rhel.7-x64.runtime.native.System.Security.Cryptography.OpenSsl": {
    "type": "Transitive",
    "resolved": "4.3.0",
    "contentHash": "T5NvFgmHX0WH4c7lP72krsnk+IJI10vJf2j2twGE+5QBRA4RyRAgD+ZjEgdmpLOjW4B+nZGaadewTCUcR899OQ=="
...
  "System.Collections.NonGeneric": {
    "type": "Transitive",
    "resolved": "4.3.0",
    "contentHash": "LE/oChpRvkSi3U25u0KnJcI44JeDZ1QJCyN4qFDx2uusEypdqR24w7lKYw21eYe5esuCBuc862wRmpF63Yy1KQ==",

On Machine B, dotnet restore --force-evaluate instead produces

...
  "runtime.native.System.IO.Compression": {
    "type": "Transitive",
    "resolved": "4.3.0",
    "contentHash": "INBPonS5QPEgn7naufQFXJEp3zX6L4bwHgJ/ZH78aBTpeNfQMtf7C6VrAFhlq2xxWBveIOWyFzQjJ8XzHMhdOQ==",
...
  "runtime.rhel.7-x64.runtime.native.System.Security.Cryptography.OpenSsl": {
    "type": "Transitive",
    "resolved": "4.3.0",
    "contentHash": "nyFNiCk/r+VOiIqreLix8yN+q3Wga9+SE8BCgkf+2BwEKiNx6DyvFjCgkfV743/grxv8jHJ8gUK4XEQw7yzRYg=="
...
  "System.Collections.NonGeneric": {
    "type": "Transitive",
    "resolved": "4.3.0",
    "contentHash": "prtjIEMhGUnQq6RnPEYLpFt8AtLbp9yq2zxOSrY7KJJZrw25Fi97IzBqY7iqssbM61Ek5b8f3MG/sG1N2sN5KA==",
...

As you can see, the content hashes for packages are different, although the versions are the same.

We have seen #7682, and we have cleared both C:\Users\User\.nuget\packages and C:\Program Files\dotnet\sdk\NuGetFallbackFolder, as instructed in that issue. We also (as seen below) have NuGet versions later than 4.9.3 (which is the version where #7682 is fixed). And finally, we do not see all hashes changing, just the three mentioned above.

Machine A info:

> dotnet --version
2.2.402
> dotnet nuget --version
NuGet Command Line
5.2.0.3

Machine B info:

> dotnet --version
2.2.108
> dotnet nuget --version
NuGet Command Line
4.9.4.0

Verbose Logs

The output from dotnet restore --force-evaluate --verbosity diag are attached as MachineA.txt and MachineB.txt
MachineA.txt

MachineB.txt

[zkat]

That's strange. Thanks for the bug report. I have a question: Does this still happen if you upgrade Machine B to the same dotnet/nuget version as Machine A?

[erik-kallen]

I can check tomorrow, but as a sidetrack I tested to install SDK 2.2.108 on Machine A.

I then created a global.json to select 2.2.108 for my project and ran dotnet restore --force-evaluate. This resulted in the following new hashes:

      "runtime.opensuse.13.2-x64.runtime.native.System.Security.Cryptography.OpenSsl": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "zWLOQ77Y4FV/6Vw2g+FYzprbQX5/xKvjoCLe4L9159Aw1bSboQoJ1KRZFNdexDooWRAIsLSdE0ZokkrVkwN8Yw=="
      },
      "runtime.osx.10.10-x64.runtime.native.System.Security.Cryptography.OpenSsl": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "/p8IQT2brFMDa7BHMH71LV+w5Tb3OxoLHxhn6+MGqN5xeqhM2HRHmj+7xQGJnaRn73d7ZTvp6yRCFMvolws4wA=="
      },
      "runtime.rhel.7-x64.runtime.native.System.Security.Cryptography.OpenSsl": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "T5NvFgmHX0WH4c7lP72krsnk+IJI10vJf2j2twGE+5QBRA4RyRAgD+ZjEgdmpLOjW4B+nZGaadewTCUcR899OQ=="
      },
      "runtime.ubuntu.14.04-x64.runtime.native.System.Security.Cryptography.OpenSsl": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "JGc0pAWRE8lB4Ucygk2pYSKbUPLlAIq6Bczf5/WF2D/VKJEPtYlVUMxk8fbl1zRfTWzSHi+VcFZlaPlWiNxeKg=="
      },
      "runtime.ubuntu.16.04-x64.runtime.native.System.Security.Cryptography.OpenSsl": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "YWzJvhiC+iLWI/IfpPQUIBhYnAHUFQFRDqR7VDNmPj0b3rjW7dArFqKysZ9v0iSBs9Ih4v9GasLpYCSUwADMQQ=="
      },
      "runtime.ubuntu.16.10-x64.runtime.native.System.Security.Cryptography.OpenSsl": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "1uVTITQP8/cI6YoO6FqfW1pzP0k2TnDZ3TFD88Bu/9H7ZuTsMY9xmadbGpwPu8w8swcd1ifZJsjD9hF9O6C/tg=="
      },
      "System.Security.Cryptography.OpenSsl": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "vOYy7Jv9KsG3ld2hLt0GoERd82SZi4BelrbXLwI9yFBYX7kpbvUCWYo4eyevk47cuJXZ9ZLVAryANcc7iY71aA==",
      "System.Xml.XmlSerializer": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "VShQJhOxgD/5M2Z1IWm1vMaSqlbjo1zdFf8H7Ahte6bTvSUhUko/gDpAVVhGgGgTDeue4QyNg1fu1Zz2GKSEuQ==",

Even if I delete the global.json afterwards (or switch it to use 2.2.402), the hashes still remain the new ones, so it seems like the mere act of installing an SDK (or perhaps running a single install once) has caused the hashes to somehow be permanently changed. Also, I am on Windows, in case it matters

[zkat]

This is possibly a duplicate of #7921. Could you try the steps in #7921 (comment) to see if that helps, as well?

[erik-kallen]

I followed the steps, and now it is working.

Note that, contrary to what #7921 (comment) seems to say,
<DisableImplicitNuGetFallbackFolder>true</DisableImplicitNuGetFallbackFolder> was required for me.

Also, that issue is closed, but I think this issue should still be open. Needing to find these comments and adding secret .csproj properties is not a good experience, so my vote is that the issue needs to be fixed so it works by default.

[CMThF]

We run into the exact same issue, with different dependencies on every machine.
However, DisableImplicitNuGetFallbackFolder does not circumvent it here.

[stevenvolckaert]

We run into the exact same issue, with different dependencies on every machine.
However, DisableImplicitNuGetFallbackFolder does not circumvent it here.

I was able to resolve this by following the steps exactly as outlined in NuGet/Home #7921.

Hope this helps!

[CMThF]

Yeah, already saw that entry. We have the exact same settings - no success.

[nkolev92]

Closing as a duplicate of #7921.