nuget: NU1107 Version conflict detected for Microsoft.Extensions.Logging" - how to fix
Fixes NuGet error NU1107 version conflict detected for Microsoft.Extensions.Logging. Use it when dotnet restore fails naming a diamond dependency on a Microsoft.Extensions package. Key trigger: two referenced packages pull different versions of the same Extensions library, and the fix is a direct PackageReference to the higher version in the consuming project (nearest wins), or one shared version via Central Package Management.
TL;DR: Two of your dependencies each demand a different version of Microsoft.Extensions.Logging and NuGet refuses to guess. Add an explicit PackageReference to the newer version in the project that consumes both, because the nearest reference wins the conflict. Restore again and the NU1107 goes away. For repos with many projects, Central Package Management pins one version everywhere.
The error
"nuget: NU1107 Version conflict detected for Microsoft.Extensions.Logging" - how to fixSteps to fix
Find the diamond: dotnet list YourProject.csproj package --include-transitive | grep -i Extensions.Logging (adjust the project path). Expected: You see two different versions of Microsoft.Extensions.Logging coming in through two different parents.
Add a direct reference to the higher version in the top-level project: a PackageReference line for Microsoft.Extensions.Logging with the newer version number. Expected: The project file now declares the version explicitly.
Run dotnet restore --force-evaluate (or delete obj/project.assets.json and run dotnet restore). Expected: Restore completes with no NU1107 error.
Build and run tests. Expected: The build succeeds and tests pass against the single chosen version.
Optional, for multi-project repos: enable Central Package Management and declare the Extensions.Logging version once in Directory.Packages.props. Expected: All projects resolve the same version and future diamonds are prevented.
Use this when
- dotnet restore fails with NU1107 naming Microsoft.Extensions.Logging after a package upgrade
- Two NuGet packages pull conflicting versions of any Microsoft.Extensions.* library
- An upgrade PR needs the manual diamond-dependency fix for the .NET dependency graph
Not for this skill when
- NU1101 (package not found) or NU1100 (unable to resolve), which are availability problems
- NU1605 downgrade warnings treated as errors, which are a different rule
- Assembly binding redirect issues at runtime, which happen after restore succeeds
Variant phrasings
- NU1107 version conflict detected for Microsoft.Extensions.DependencyInjection
- dotnet restore fails with package downgrade detected
- transitive NuGet dependency version conflict
Why it happens
NuGet uses nearest-wins: the version closest to your project in the dependency graph is chosen. When two transitive paths are equally near but demand different versions of the same package, there is no nearest winner and NuGet reports NU1107 rather than picking arbitrarily. A direct PackageReference is distance zero, so it always wins and ends the ambiguity. Microsoft.Extensions libraries are the classic trigger because nearly every .NET package depends on them.
Edge cases
- Pinning the higher version can break the package that wanted the lower one; run that package's tests, not just yours.
- If both parents are third-party and incompatible with a single version, you may need binding redirects or to upgrade one parent first.
- Central Package Management changes restore behavior repo-wide; enable it deliberately, not mid-upgrade.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_zGiBPPWefo3bSvGfM7wfeA