NuGet lock file fails to restore with --locked-mode

Question

Roslyn gave us deterministic builds a few years ago.

And with the addition of NuGet lock files, we can finally have guaranteed reproducible build.

I'm looking at the docs that say I can opt-in with

--use-lock-file Bootstraps use of lock file for a project. You can alternatively set RestorePackagesWithLockFile property in the project file

And will require a lock file when restoring with:

--locked-mode Enables locked mode for restore. This is useful in CI/CD scenarios where you would like to get the repeatable builds. This can be also by setting the RestoreLockedMode MSBuild property to true

I'm trying it out by modifying the Directory.Build.props at the root of the repo:

   <PropertyGroup>
     ...
+    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
   </PropertyGroup>

When I run dotnet restore, I see the lock files generated:

    benchmarks/Sentry.Benchmarks/packages.lock.json
    samples/Sentry.Samples.AspNetCore.Basic/packages.lock.json
    ...
    test/Sentry.Tests/packages.lock.json

Now if I try to restore: dotnet restore --locked-mode, it fails completely. A summary of the output is:

/Users/bruno/git/sentry-dotnet/test/Sentry.Tests/Sentry.Tests.csproj : error NU1603: System.Private.DataContractSerialization 4.1.1 depends on System.Xml.XmlDocument (>= 4.0.1) but System.Xml.XmlDocument 4.0.1 was not found. An approximate best match of System.Xml.XmlDocument 4.3.0 was resolved. [/Users/bruno/git/sentry-dotnet/Sentry.sln]
/Users/bruno/git/sentry-dotnet/test/Sentry.Tests/Sentry.Tests.csproj : error NU1603: System.Xml.XPath.XmlDocument 4.0.1 depends on System.Xml.XmlDocument (>= 4.0.1) but System.Xml.XmlDocument 4.0.1 was not found. An approximate best match of System.Xml.XmlDocument 4.3.0 was resolved. [/Users/bruno/git/sentry-dotnet/Sentry.sln]
  Restore failed in 383.47 ms for /Users/bruno/git/sentry-dotnet/test/Sentry.NLog.Tests/Sentry.NLog.Tests.csproj.
  Restore failed in 370.7 ms for /Users/bruno/git/sentry-dotnet/test/Sentry.Testing/Sentry.Testing.csproj.

I must be getting something totally wrong here.

PS: I've pushed the changes to a branch and opened a PR on GitHub if one is interested to taking a look.

EDIT: Jan 2021: 1 and half year later I tried again with the .NET 5 SDK, and I still have problems: https://github.com/getsentry/sentry-dotnet/pull/731

I've tried DisableImplicitNuGetFallbackFolder without success. The lock file seem to be platform dependant.

In CI it works properly on macOS and Linux but fails on Windows. I created the lock file on a Mac. I pulled the branch on Windows and it indeed fails with:

error NU1403: Package content hash validation failed for System.Net.Http.4.3.0. The package is different than the last restore.

I'd bet money it's using the file path separator such as / when calculating the hash and that's the reason for the failure.

Odilo

Hi, any updates on this? I am having exactly the same issue. – Moiety

Answer 1

Cross-platform stable lock-files should be possible by adding RuntimeIdentifiers to your PropertyGroup, e.g. <RuntimeIdentifiers>win-x64;linux-x64;osx-x64</RuntimeIdentifiers>

Wouldbe

This definitely worked for me. Every time I would cross compile before, my locks would change. Now they have entries for each RuntimeIdentifier. Thanks! – Sudan

How does that affect build time and other things? My experience by adding RID in the past was negative in some cases unless I wanted to build self contained apps, or apps that were targeting specific platforms – Odilo