NuGet: 'error NU1107: Version conflict detected. Install/reference directly to resolve this issue'

error NU1107: Version conflict detected for Microsoft.CodeAnalysis.Common. Install/reference Microsoft.CodeAnalysis.Common 4.9.2 directly to project ConflictLab to resolve this issue. Two of your packages each demand an exact, different version of the same dependency, and NuGet cannot pick one. The clean fix is to put the packages that demand it on the same version.

Read the two chain lines under the error: they name the packages that pull the dependency in and the version each insists on. Align those packages. The hint in the message, a direct reference to the dependency, makes restore pass but leaves one package on a version it was not built for.

The error

  Determining projects to restore...
...\ConflictLab\ConflictLab.csproj : error NU1107: Version conflict detected for Microsoft.CodeAnalysis.Common. Install/reference Microsoft.CodeAnalysis.Common 4.9.2 directly to project ConflictLab to resolve this issue.
...\ConflictLab\ConflictLab.csproj : error NU1107:  ConflictLab -> Microsoft.CodeAnalysis.VisualBasic 4.9.2 -> Microsoft.CodeAnalysis.Common (= 4.9.2)
...\ConflictLab\ConflictLab.csproj : error NU1107:  ConflictLab -> Microsoft.CodeAnalysis.CSharp 4.8.0 -> Microsoft.CodeAnalysis.Common (= 4.8.0).
  Failed to restore ...\ConflictLab\ConflictLab.csproj (in 1.64 sec).

Build FAILED.

The project paths are shortened; nothing else in the output was changed.

Why it happens

The (= 4.8.0) in the chain lines is an exact pin. The package's own .nuspec in the NuGet cache shows it: Microsoft.CodeAnalysis.CSharp 4.8.0 declares Microsoft.CodeAnalysis.Common with version="[4.8.0, 4.8.0]", and Microsoft.CodeAnalysis.VisualBasic 4.9.2 declares version="[4.9.2, 4.9.2]". A range with the same lower and upper bound allows exactly one version. With one chain demanding exactly 4.8.0 and the other exactly 4.9.2, no single version fits both, so restore stops.

Here the cause was two releases of one package family in one project: CSharp left on 4.8.0 while VisualBasic was on 4.9.2.

The fix

<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.9.2" />
<PackageReference Include="Microsoft.CodeAnalysis.VisualBasic" Version="4.9.2" />

dotnet build
dotnet run

With both packages on 4.9.2 the build reported 0 warnings and the app ran. Updating every member of the family to the same release is the change to make; a Directory.Packages.props with central package management makes it hard to drift again.

Following the hint literally also gets past restore, but look at what it says:

dotnet add package Microsoft.CodeAnalysis.Common --version 4.9.2

warn : NU1608: Detected package version outside of dependency constraint: Microsoft.CodeAnalysis.CSharp 4.8.0 requires Microsoft.CodeAnalysis.Common (= 4.8.0) but version Microsoft.CodeAnalysis.Common 4.9.2 was resolved.

The build succeeded with one NU1608 warning (the summary counts it twice), and the CSharp 4.8.0 package now runs on a Common it was never released with. Keep that only when no aligned versions exist.

How it was reproduced

A net10.0 console project on .NET SDK 10.0.403 referencing Microsoft.CodeAnalysis.CSharp 4.8.0 and Microsoft.CodeAnalysis.VisualBasic 4.9.2, built with dotnet build. Raising CSharp to 4.9.2 fixed it.

Frequently asked

What does NU1107 version conflict detected mean?

Two packages in your project each require an exact, different version of the same dependency, shown as (= x.y.z) in the chain lines. NuGet cannot satisfy both, so restore fails.

Should I reference the conflicting package directly as NU1107 suggests?

It makes restore pass, but NuGet then warns with NU1608 that one package runs on a version outside its constraint. Prefer updating the packages that pin it to the same release.

How do I find which packages cause NU1107?

Read the lines under the error. Each one is a chain from your project through a package you reference to the conflicting dependency, with the exact version that chain requires.

More decoded errors in the Fixes category. When a direct reference is lower than what a dependency needs, the error is different; see NU1605: Detected package downgrade.