Option to explicitly ignore `packages.lock.json` file when present on disk

[GauteAtSemine]

We are requesting a documented feature or MSBuild property that allows users to explicitly ignore an existing packages.lock.json file during the NuGet restore process.

Scenario

We operate projects in two distinct modes:

1. "Package Mode": The default, where a committed packages.lock.json file is used to lock internal, floating-version package references, ensuring deterministic historical builds.
2. "Project Mode": A specific Condition (detected by solution name) where we switch from PackageReference to ProjectReference for internal dependencies (e.g., in a monolith or Aspire application). In this mode, the lock file should be entirely ignored, as direct project references supersede it.

Problem

In previous tooling versions, simply not defining RestorePackagesWithLockFile allowed us to ignore the on-disk lock file seamlessly. In recent .NET SDK and NuGet versions, the presence of a packages.lock.json file automatically triggers validation and modification (adding "type": "Project" entries) during the solution restore phase in Visual Studio and the CLI. This breaks our mode-switching capability and pollutes the repository with unwanted file changes.

Desired Behavior

We require a reliable mechanism (an MSBuild property like <NuGetIgnoreLockFile>true</NuGetIgnoreLockFile>) to disable the lock file feature entirely for a specific restore operation, even if the packages.lock.json file exists on disk.

This would allow us to restore the previous seamless behavior using existing MSBuild property conditions (Directory.Build.props), avoiding complex file-renaming hacks or wrapper scripts that fall outside of standard Microsoft tooling and IDE integration.

[KalleOlaviNiemitalo]

The NuGetLockFilePath property is documented at https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets. Perhaps you can make Directory.Build.props point that to a file that does not exist.

[Grastveit]

Yes, @KalleOlaviNiemitalo! Thanks. That worked.

(And it was documented. I don't know if an extra explicit ignore-property is better, or if this issue should be closed.)

[KalleOlaviNiemitalo]

I expect this issue will be closed anyway because it was not filed in the NuGet repository.

[marcpopMSFT]

CC @nkolev92

[nkolev92]

In previous tooling versions, simply not defining RestorePackagesWithLockFile allowed us to ignore the on-disk lock file seamlessly. In recent .NET SDK and NuGet versions, the presence of a packages.lock.json file automatically triggers validation and modification (adding "type": "Project" entries) during the solution restore phase in Visual Studio and the CLI. This breaks our mode-switching capability and pollutes the repository with unwanted file changes.

@GauteAtSemine When did this change?

[Grastveit]

I don't know exactly, but 4-8 weeks ago.

I had prototype of project-mode-switch running in a rarely changed project in late August. A collogue got the surprising lock-file-changes some weeks back. I did not have time to check, but speculated it might be because of Rider. (I use VS and vs-code.) Then last week, when I returned to the project, I also got the error.

[dotnet-policy-service]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!