Introduction

A detected package downgrade warning in a .NET Core project means NuGet resolved a lower package version than one part of the dependency graph expected. The build often still completes, but the warning matters because it signals that your restore graph is inconsistent and may produce runtime failures or missing APIs.

What the Warning Actually Means

NuGet builds a dependency graph from direct package references and transitive dependencies. A downgrade warning appears when one path requires a newer package version, but another path or explicit reference pulls the graph down to an older one.

A simplified example looks like this:

• your application references PackageA
• 'PackageA depends on Newtonsoft.Json 13.0.1'
• your application explicitly references Newtonsoft.Json 12.0.3

NuGet restores 12.0.3 because the top-level project pinned it, then warns that a downgrade occurred. That warning is telling you the application graph is now inconsistent with one dependency's requirement.

Fix the Conflict at the Top Level

The usual fix is to add or update a direct PackageReference in the top-level project to the version that satisfies the highest requirement.

1<Project Sdk="Microsoft.NET.Sdk">
2  <PropertyGroup>
3    <TargetFramework>net8.0</TargetFramework>
4  </PropertyGroup>
5
6  <ItemGroup>
7    <PackageReference Include="PackageA" Version="5.0.0" />
8    <PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
9  </ItemGroup>
10</Project>

This works because direct references in the application project are the clearest place to resolve the version intentionally.

Inspect the Dependency Graph Instead of Guessing

Do not fix downgrade warnings blindly. First identify which package introduced the higher version requirement.

dotnet list package --include-transitive

That command shows both direct and transitive packages so you can find the conflicting paths. If the project uses older tooling or Visual Studio restore behavior, a command-line restore is still useful because it exposes the graph more clearly than the IDE warning list.

When the graph is large, search for the package named in the warning and compare the required versions along each path.

Multi-Project Solutions Need Consistency

Downgrade warnings become more common when several projects in the same solution reference different package versions. Even if each project builds individually, the application entry point can still restore a conflicting graph.

A small example:

1<!-- LibraryA.csproj -->
2<ItemGroup>
3  <PackageReference Include="MediatR" Version="12.1.0" />
4</ItemGroup>

1<!-- App.csproj -->
2<ItemGroup>
3  <ProjectReference Include="..\LibraryA\LibraryA.csproj" />
4  <PackageReference Include="MediatR" Version="11.0.0" />
5</ItemGroup>

Here the application project pins an older version than the library expects. The clean fix is to unify the versions rather than hoping restore will “pick the right one.”

Visual Studio 2017 Context

In older Visual Studio and .NET Core setups, these warnings showed up often during migrations because project templates, SDK versions, and package baselines changed quickly. The principle is still the same: the tool is warning that your restore graph contains a conflict, not that the IDE is malfunctioning.

Treat the warning as dependency hygiene work. It is rarely solved by clearing random folders alone.

When Removing a Direct Reference Helps

Sometimes the downgrade exists only because the project still carries an explicit package reference it no longer needs. If a transitive dependency now brings the correct version, removing the stale direct reference can eliminate the conflict.

That is especially common after framework upgrades or when older compatibility packages remain in the project long after they stopped being necessary.

Use Restore Cleanups Sparingly

If the project file is correct but Visual Studio still shows stale results, a cleanup can help:

dotnet clean
dotnet restore

This is useful after changing package references, but it is not the primary fix. If the graph still asks for incompatible versions, the warning will return immediately.

Common Pitfalls

The most common mistake is suppressing the warning instead of resolving the version conflict. That hides the symptom while leaving the dependency graph inconsistent.

Another mistake is updating only one project in a multi-project solution. The entry point project often needs the explicit version decision.

Developers also clear caches before reading the warning carefully. The warning already names the package and the paths involved, so start there.

Finally, avoid assuming the lowest version is safe because the project still compiles. Compile-time success does not prove runtime compatibility.

Summary

• A downgrade warning means NuGet restored an older package than some dependency path expected.
• Fix the conflict at the top-level project with an explicit compatible version.
• Inspect transitive dependencies before changing package versions.
• Keep package versions consistent across related projects.
• Use clean and restore as a follow-up step, not as the main solution.