NuGet Package Version Conflict Explainer

How to use this tool

1. Copy the relevant section of a failed dotnet restore/dotnet build output — the lines containing NU1605, NU1107, or NU1608 and the indented dependency-chain lines directly under them.
2. Alternatively, paste the output of dotnet list package --include-transitive.
3. Click Explain (or Ctrl+Enter).
4. Copy whichever resolution snippet fits your situation — each is customized with the actual package names parsed from your input.

What this tool does

NuGet's own console output tells you that a version conflict happened, but the dependency chain that caused it is buried in indented arrow-separated lines that are easy to misread under a wall of build output. This tool parses that text with a set of rules matched against NuGet's documented warning/error formats, extracts the package name and the competing versions, and generates three ready-to-paste fixes customized with the names it found. Everything runs in your Blazor Server session — nothing is sent to an external API, and no NuGet client library or MSBuild dependency is involved in the parsing itself.

The three warning/error codes this tool recognizes

Worked example

Pasting this restore output:

warning NU1605: Detected package downgrade: Microsoft.Extensions.Logging.Abstractions from 8.0.1 to 8.0.0. Reference the package directly from the project to select a different version.
 MyApi -> Microsoft.Extensions.Logging.Abstractions (>= 8.0.1)
 MyApi -> Serilog.Extensions.Logging 8.0.0 -> Microsoft.Extensions.Logging.Abstractions (>= 8.0.0)

produces the conflict summary above and a direct-pin snippet reading <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="8.0.1" /> — the higher of the two versions in the chain, which satisfies both paths.

The three resolution strategies

Direct reference pinning adds an explicit PackageReference for the conflicting package to the project that has the conflict — a direct reference always wins over a transitive one, regardless of what any dependency asked for. Fastest fix, but has to be repeated in every project that hits the same conflict.

Directory.Packages.props central pinning (Central Package Management, NuGet 6.2+) moves every package's version to one file at the solution root, so a fix applies to every project at once instead of one .csproj at a time. Existing .csproj files drop their Version attribute once ManagePackageVersionsCentrally is enabled.

Fixing the version range at the source means upgrading the intermediate package that's pulling in the wrong transitive version — often a newer release of that package already depends on a compatible version, which resolves the conflict without pinning anything by hand.

Pasting `dotnet list package --include-transitive` instead

If you don't have the original restore warning text saved, paste the output of dotnet list package --include-transitive instead. This tool recognizes its Top-level Package / Transitive Package table headers and lists every package and resolved version it finds — since a single target framework's resolved package list doesn't itself state a conflict the way an NU1605/NU1107/NU1608 line does, this mode shows you what actually got resolved so you can cross-check it against a restore warning, rather than inventing a conflict that isn't stated in the text.

What this tool can't do

It doesn't run dotnet restore, doesn't query nuget.org for real package metadata, and doesn't know which fix is architecturally correct for your project — it only extracts what's already stated in the text you paste in and applies the same three standard fixes every time. If the input doesn't match any of the recognized formats, you get an honest "couldn't parse this" message and the same three strategies explained generically, rather than a guess dressed up as an answer.