Fix 'Could not load file or assembly' Error in .NET Applications on Windows

The Error

Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.

Build succeeds. App crashes. That's the maddening part — this is a runtime failure, not a compile-time one. Your IDE gives you zero warning before it blows up in production.

Root Cause

The CLR (Common Language Runtime) demands an exact version match when loading assemblies. Miss by even a minor version and it bails out. Three things cause this:

Version mismatch: One package references Newtonsoft.Json 12.0.0.0, but 13.0.0.0 is what landed in the output directory. The CLR looks for 12, finds 13, refuses to load it.
Missing DLL: The assembly wasn't copied to the output or publish folder — either skipped as a dependency or trimmed during publish.
Broken binding redirect: .NET Framework apps use <bindingRedirect> in app.config or web.config to say "version 12 is fine, use 13." No redirect — or a wrong one — and the runtime dies here.

Fix 1: Restore NuGet Packages

Nine times out of ten, pulling from git or switching branches corrupts something in the local package cache. Start here before anything else.

# In the project or solution directory
dotnet restore

# Or with NuGet CLI
nuget restore YourSolution.sln

Then rebuild:

dotnet build --configuration Release

Verify the DLL actually landed in the output:

dir bin\Release\net6.0\Newtonsoft.Json.dll

If it's missing here, the crash makes perfect sense. Fix the copy step before touching anything else.

Fix 2: Add or Fix a Binding Redirect (.NET Framework)

On .NET Framework, the runtime uses App.config or Web.config to resolve version mismatches. Open yours and find the <runtime> section. No binding redirect for the failing assembly? Add one:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json"
                          publicKeyToken="30ad4fe6b2a6aeed"
                          culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-13.0.0.0"
                         newVersion="13.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Swap 13.0.0.0 for whatever's actually installed. Check with:

dotnet list package | findstr Newtonsoft

Prefer not to hand-edit XML? Visual Studio can regenerate these automatically. Go to Tools → NuGet Package Manager → Manage Packages for Solution, consolidate the versions, and let it rewrite the config for you.

Fix 3: Consolidate Package Versions Across Projects

Multi-project solutions are where this gets messy. ProjectA uses Newtonsoft.Json 12.0.3. ProjectB uses 13.0.3. At runtime, whichever version loses the coin flip ends up missing, and the CLR complains.

Find every reference across the solution first:

# PowerShell — find all Newtonsoft.Json references across projects
Get-ChildItem -Recurse -Filter "*.csproj" | Select-String "Newtonsoft.Json"

Then pin everything to the same version:

dotnet add package Newtonsoft.Json --version 13.0.3

For a permanent fix, use a Directory.Packages.props file (Central Package Management) to define the version once for the whole solution:

<!-- Directory.Packages.props -->
<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
  </ItemGroup>
</Project>

After that, strip Version="..." from every .csproj — they inherit from the central file. Version drift becomes impossible by design.

Fix 4: Force Copy to Output Directory

Sometimes the DLL sits in the NuGet cache but never makes it to the build output. Check the .csproj for any ExcludeAssets or PrivateAssets flags that block the runtime copy:

<PackageReference Include="Newtonsoft.Json" Version="13.0.3">
  <!-- Remove any ExcludeAssets or PrivateAssets that block runtime -->
</PackageReference>

For a raw assembly reference (not from NuGet), set Private to true so it copies on every build:

<Reference Include="Newtonsoft.Json">
  <HintPath>..\libs\Newtonsoft.Json.dll</HintPath>
  <Private>true</Private>
</Reference>

Fix 5: Clear the NuGet Cache

A corrupted cache entry causes exactly this kind of ghost — the package appears installed, but the DLL that lands in output is wrong or truncated. Wipe it and start fresh:

# Clear all NuGet caches
dotnet nuget locals all --clear

# Then restore fresh
dotnet restore

Fix 6: Check the Publish Profile

Error only shows up after publishing, not during local dev? The publish profile is probably trimming the assembly. Disable it explicitly:

# Self-contained publish without trimming
dotnet publish -c Release --self-contained true -r win-x64 /p:PublishTrimmed=false

Or open your publish profile at Properties/PublishProfiles/*.pubxml and confirm PublishTrimmed isn't set to true for assemblies your app needs at runtime.

Verification

After the fix, confirm it actually worked — don't assume:

Rebuild: dotnet build -c Release
Check the output for the correct DLL version:dir bin\Release\**\Newtonsoft.Json.dll /s
Run the app and verify the error is gone.
For .NET Framework apps with binding redirects, use Fusion Log Viewer (fuslogvw.exe, included in the Windows SDK). Enable logging, reproduce the error, then read the log entries — it shows the full assembly probe sequence and makes a misconfigured redirect obvious in seconds.

# Launch Fusion Log Viewer
fuslogvw.exe

Prevention

Central Package Management removes version drift entirely in multi-project solutions. One props file, one source of truth, no surprises.
Audit regularly: run dotnet list package --outdated periodically. Transitive dependency gaps are far easier to close when they're two versions behind, not ten.
Ban floating versions in CI — no * or 13.* in production builds. Pin to a specific version and update deliberately.
When inspecting *.deps.json or other JSON manifests that .NET generates alongside your build output, ToolCraft's JSON Formatter lets you validate and explore the structure without spinning up an IDE.