Question
project.assets.json lock file not rolled back after a failed NuGet package upgrade
Sky Orbit
0 reputation · 27 Mar 2020, 05:15 UTC
65.6K views
Loading…
0 reputation · 27 Mar 2020, 05:15 UTC
Starting with NuGet 4.0, each restore operation writes a project.assets.json lock file that records the resolved package graph. When a restore fails part‑way through, the lock file can be left in a partially written or corrupted state. NuGet does not automatically rollback or invalidate this file, so subsequent builds fail until the lock file is removed or overwritten by a successful restore.
The goal is to understand whether this behavior is intentional, what constraints prevent an automatic recovery, and if any configuration or future changes could alter the outcome.
Is there a configuration switch that would cause NuGet to treat a partially written lock file as invalid and trigger a fresh restore automatically? Should NuGet emit a distinct warning or error code indicating lock‑file corruption instead of a generic restore failure? Are there plans to adopt an atomic write or temporary‑file strategy for the lock file to avoid partial writes?
35275 reputation · 27 Mar 2020, 16:17 UTC
There is currently no configuration switch in NuGet to automatically detect a partially written project.assets.json file and trigger a fresh restore. Because the restore process is not transactional, a failure during the write phase can leave the lock file in an inconsistent state that blocks subsequent builds.
To resolve a corrupted lock file and synchronize your project state, perform a clean restore by removing the build artifacts:
nugetobj folder in the affected project directory. This removes the project.assets.json file entirely.dotnet restoreproject.assets.json has been regenerated and matches the versions defined in your .csproj file.The project.assets.json file serves as the resolved dependency graph. In current NuGet implementations, this file is updated to reflect the intended state defined in the project file. If the process is interrupted—due to network failure, disk I/O errors, or package unavailability—the file may remain partially written. NuGet treats the presence of the file as a signal that a restore has occurred, regardless of whether that restore completed successfully.
The lack of automatic rollback is primarily due to the non-transactional nature of the restore operation. Implementing an atomic write (writing to a temporary file and renaming it) would mitigate partial writes, but the broader issue is the synchronization between the .csproj (the source of truth) and the project.assets.json (the resolved state). If the project file was updated but the restore failed, the lock file is effectively obsolete.
To determine if your failure is specifically due to a corrupted lock file rather than a package resolution error, compare the .csproj version entries against the entries in project.assets.json. If the lock file contains versions not present in the project file, or is syntactically invalid JSON, the lock file is the primary blocker.
Missing Detail: Are you using a specific CI/CD agent or a shared network drive for the obj folder? File locking behaviors on network shares can increase the frequency of partial writes.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 27 Mar 2020, 06:46 UTC
NuGet 4.0+ stores the resolved dependency graph in project.assets.json, but the restore operation writes this file incrementally without transactional safety. When a restore fails mid‑write, the lock file can retain a partially populated package graph, which subsequent builds read as valid and then fail or produce mismatched references. This non‑atomic write pattern means the file is never automatically invalidated, and the only reliable recovery is to delete the obj folder or remove the file manually before re‑running dotnet restore.