Introduction

Error CS1705 occurs when a .NET project references assembly A, which depends on a specific version of assembly B, but the project also references a different (lower) version of assembly B. The compiler cannot resolve the version conflict because assembly A expects a higher version than what is available. The fix involves aligning assembly versions by updating NuGet packages, adding binding redirects, or ensuring all projects in a solution target compatible dependency versions.

What the Error Looks Like

1error CS1705: Assembly 'LibraryA' with identity 'LibraryA, Version=2.0.0.0'
2uses 'Newtonsoft.Json, Version=13.0.0.0' which has a higher version than
3referenced assembly 'Newtonsoft.Json' with identity
4'Newtonsoft.Json, Version=12.0.0.0'

This means LibraryA was compiled against Newtonsoft.Json version 13, but your project only has version 12 available.

Why This Happens

.NET assemblies have strong version identities. When assembly A is compiled against assembly B version 2.0, it records that dependency. If your project provides assembly B version 1.0, the compiler detects the mismatch:

1Your Project
2├── References LibraryA (compiled against Newtonsoft.Json 13.0)
3├── References Newtonsoft.Json 12.0  ← Version too low!
4└── CS1705 error

Common causes:

• Two NuGet packages depend on different versions of the same library
• A project was upgraded but not all dependencies were updated
• Manual assembly references point to an old DLL

Fix 1: Update the Lower-Version Package

The most straightforward fix — update the outdated package to match or exceed the required version:

1# Update a specific package
2dotnet add package Newtonsoft.Json --version 13.0.3
3
4# Or in Package Manager Console
5Update-Package Newtonsoft.Json -Version 13.0.3

<!-- Verify in .csproj -->
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />

Fix 2: Binding Redirects (.NET Framework)

For .NET Framework projects, binding redirects in app.config or web.config tell the runtime to use a specific version regardless of what was requested:

1<!-- app.config or web.config -->
2<configuration>
3  <runtime>
4    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
5      <dependentAssembly>
6        <assemblyIdentity name="Newtonsoft.Json"
7                          publicKeyToken="30ad4fe6b2a6aeed"
8                          culture="neutral" />
9        <bindingRedirect oldVersion="0.0.0.0-13.0.0.0"
10                         newVersion="13.0.0.0" />
11      </dependentAssembly>
12    </assemblyBinding>
13  </runtime>
14</configuration>

Enable automatic binding redirect generation in the .csproj:

1<PropertyGroup>
2  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
3  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
4</PropertyGroup>

Fix 3: Consolidate Package Versions

When multiple projects in a solution use different versions:

1# Check for version inconsistencies across the solution
2dotnet list package --include-transitive
3
4# Update all projects to the same version
5dotnet add ProjectA/ProjectA.csproj package Newtonsoft.Json --version 13.0.3
6dotnet add ProjectB/ProjectB.csproj package Newtonsoft.Json --version 13.0.3

In Visual Studio, use the NuGet Package Manager's "Consolidate" tab to find and fix version mismatches across projects.

Central Package Management (Recommended)

Use Directory.Packages.props to enforce consistent versions across the entire solution:

1<!-- Directory.Packages.props (at solution root) -->
2<Project>
3  <PropertyGroup>
4    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
5  </PropertyGroup>
6  <ItemGroup>
7    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
8    <PackageVersion Include="Microsoft.Extensions.Logging" Version="8.0.0" />
9  </ItemGroup>
10</Project>

<!-- Individual .csproj files — no version attribute needed -->
<PackageReference Include="Newtonsoft.Json" />

Fix 4: Clean and Rebuild

Stale DLLs in the output directory can cause phantom version conflicts:

1# Clean all build artifacts
2dotnet clean
3rm -rf bin/ obj/
4
5# Restore and rebuild
6dotnet restore
7dotnet build

Fix 5: Check Transitive Dependencies

A transitive dependency (dependency of a dependency) may require a higher version:

1# List all packages including transitive ones
2dotnet list package --include-transitive
3
4# Look for version conflicts
5dotnet list package --include-transitive --outdated

<!-- Force a specific version by adding a direct reference -->
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />

Adding a direct reference to the conflicting package at the required version overrides the transitive version.

Diagnosing the Issue

1# Find which assemblies reference which versions
2# Use the Fusion Log Viewer (fuslogvw.exe) on .NET Framework
3
4# Or use ILSpy/dotPeek to inspect assembly references
5# Right-click the DLL → Open with ILSpy → References
6
7# Check assembly version in code
8var assembly = typeof(Newtonsoft.Json.JsonConvert).Assembly;
9Console.WriteLine(assembly.GetName().Version);  // 13.0.0.0
10Console.WriteLine(assembly.Location);           // Full path

Common Pitfalls

• Updating only one project in a multi-project solution: If ProjectA updates Newtonsoft.Json to 13.0 but ProjectB stays on 12.0, CS1705 occurs when ProjectA references ProjectB. Update all projects to the same version.
• Relying on binding redirects without understanding the cause: Binding redirects mask the version mismatch at runtime but do not fix the root cause. If the newer version has breaking changes, the redirect causes runtime errors instead of compile errors.
• Stale DLLs in bin/obj directories: Old assembly versions cached in build output cause false CS1705 errors. Always dotnet clean and delete bin/ and obj/ before troubleshooting version conflicts.
• Mixing .NET Framework and .NET Standard packages: Some packages have different version numbers for .NET Framework vs .NET Standard. Ensure the target framework of all projects is compatible with the package versions referenced.
• Not checking transitive dependencies: The conflict may not be in a package you directly reference. Use dotnet list package --include-transitive to find hidden version mismatches in dependency chains.

Summary

• CS1705 means one assembly expects a newer version of another assembly than what your project provides
• Update the outdated package to the required version with dotnet add package
• Use binding redirects in .NET Framework projects to redirect old version requests to the installed version
• Use Central Package Management (Directory.Packages.props) to enforce consistent versions across a solution
• Clean build artifacts and check transitive dependencies when the error persists after updating