Skip to content
Latchkey

NuGet "package is not compatible" / Corrupt Cache - Clear It in CI

A package in the global-packages cache is corrupt or half-downloaded, so restore fails validating it. Clearing the NuGet caches forces a clean re-download.

What this error means

Restore fails with a hash/signature mismatch or claims a package is missing even though the feed has it, often after an interrupted earlier restore or a bad cache restore key. Clearing the cache fixes it.

dotnet restore output
error : The package is not found in the following sources, or the local cache is corrupt.
error : NU3008: The package integrity check failed. The package has changed since it was signed.

Common causes

Partial or interrupted download in the cache

A restore that was killed mid-download (timeout, OOM, cancellation) can leave a truncated package in ~/.nuget/packages, which later restores then reject.

A poisoned CI cache key

A cache restore that mixes packages from different runs, or a key collision, can place an inconsistent package set into the global folder.

How to fix it

Clear the NuGet caches and re-restore

Wipe the local caches so restore re-downloads everything cleanly.

Terminal
dotnet nuget locals all --clear
dotnet restore

Key the package cache on the lock file

A precise cache key keyed on the lock file avoids mixing incompatible package sets.

.github/workflows/ci.yml
- uses: actions/cache@v4
  with:
    path: ~/.nuget/packages
    key: nuget-${{ runner.os }}-${{ hashFiles('**/packages.lock.json') }}

How to prevent it

  • Key the NuGet cache on the lock file so it stays consistent.
  • Avoid sharing one cache across unrelated branches or runner OSes.
  • Add a dotnet nuget locals all --clear fallback step when integrity errors recur.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →