NuGet package conflicts can be frustrating, especially when Visual Studio reports an error involving packages that you never directly installed. You may see messages such as NU1107, NU1605, or other dependency-related warnings and errors without immediately knowing which package is responsible.

The good news is that you don't have to guess. Visual Studio and the .NET CLI provide several ways to inspect your project's dependency tree and identify exactly which NuGet package is introducing the conflict.

In this guide, we'll walk through the easiest ways to find the package causing a NuGet dependency conflict and then determine the best way to fix it.

---

🔍 What Is a NuGet Dependency Conflict?

A NuGet dependency conflict occurs when two or more packages require incompatible versions of the same dependency.

For example, imagine your application references two packages:

Your Application
    │
    ├── Package A
    │      └── Newtonsoft.Json 12.x
    │
    └── Package B
           └── Newtonsoft.Json 13.x

Both packages depend on Newtonsoft.Json, but they require different versions.

NuGet then has to determine which version can be used. Depending on the dependency requirements, this can result in a warning or an error.

---

🚨 Why Is It Sometimes Difficult to Find the Problem?

The package causing the conflict is not always a package that you explicitly installed.

For example:

YourProject
    │
    ├── PackageA
    │      └── DependencyX
    │             └── DependencyY
    │
    └── PackageB
           └── DependencyY

Your project only references PackageA and PackageB, but both packages eventually depend on DependencyY.

This is called a transitive dependency.

Therefore, looking only at the packages listed directly in your .csproj file may not be enough.

---

🥇 Method 1: Read the Complete NuGet Error

The first thing you should do is read the complete warning or error message in Visual Studio.

Open:

View
→ Error List

Look for messages containing codes such as:

• NU1107 – version conflict
• NU1605 – package downgrade
• NU1603 – dependency version resolution issue

The error message often contains the dependency chain that led to the conflict.

For example, you might see something similar to:

NU1107: Version conflict detected for PackageX.
Install/reference PackageX 5.0.0 directly to project
to resolve this issue.

The important information is the package name and the versions mentioned in the message.

---

📦 Method 2: Check Installed NuGet Packages in Visual Studio

Visual Studio provides a convenient interface for viewing the packages installed in your project.

1. Right-click your project in Solution Explorer.
2. Select Manage NuGet Packages.
3. Select the Installed tab.

You can now see the packages that your project directly references.

However, remember that this list may not show every transitive dependency responsible for a conflict.

For that, the .NET CLI is often more useful.

---

💻 Method 3: Use dotnet list package

One of the easiest ways to inspect your project's package dependencies is the .NET CLI.

Open a terminal in your project directory and run:

dotnet list package

This displays the packages referenced by your project.

You may see output similar to:

Top-level Package
> Microsoft.EntityFrameworkCore 8.0.0
> PackageA                     3.2.0
> PackageB                     4.1.0

This is useful for checking the versions of your direct package references.

---

🔎 Method 4: Include Transitive Dependencies

If you cannot find the conflicting package in the direct package list, inspect the transitive dependencies.

Run:

dotnet list package --include-transitive

This is one of the most useful commands when investigating NuGet dependency conflicts.

It shows packages that your project receives indirectly through other packages.

For example:

Top-level Package
> PackageA 3.0.0

Transitive Package
> DependencyX 5.0.0
> DependencyY 2.1.0
> DependencyZ 4.0.0

If the package mentioned in your conflict is not listed directly in your project, it may appear here.

---

🧭 Method 5: Trace the Dependency Chain

Once you identify the conflicting dependency, work backwards through the dependency tree.

For example:

Your Application
    ↓
Package A
    ↓
Package B
    ↓
Package C
    ↓
Dependency X

If Dependency X is causing the conflict, you need to find which package introduced it.

This is particularly important when the conflicting dependency is not explicitly listed in your project file.

---

🛠️ Method 6: Inspect the .csproj File

Open your project's .csproj file.

Look for PackageReference entries:

<ItemGroup>
    <PackageReference Include="PackageA" Version="3.0.0" />
    <PackageReference Include="PackageB" Version="4.0.0" />
</ItemGroup>

These are the packages your project explicitly references.

If the conflicting dependency isn't present here, it is likely being introduced transitively by one of these packages.

---

🧩 Direct vs Transitive NuGet Dependencies

📌 Direct Dependency

A direct dependency is explicitly referenced by your project:

<PackageReference Include="PackageA" Version="3.0.0" />

Your application directly requested PackageA.

📌 Transitive Dependency

A transitive dependency is installed because another package requires it:

YourProject
    ↓
PackageA
    ↓
DependencyB

Your project didn't explicitly request DependencyB. PackageA did.

This distinction is extremely important when troubleshooting package conflicts.

---

🔍 How to Find Which Package Introduced the Conflict

Suppose the error mentions:

DependencyX

but DependencyX isn't in your .csproj file.

First run:

dotnet list package --include-transitive

Find DependencyX in the output.

Then examine the packages above it and determine which top-level package introduced that dependency.

Conceptually, you are looking for a chain such as:

YourProject
    ↓
PackageA
    ↓
PackageB
    ↓
DependencyX

Once you know that PackageB introduced DependencyX, you can investigate PackageB's version and dependency requirements.

---

⚠️ What If Two Packages Require Different Versions?

Consider this example:

YourProject
    │
    ├── PackageA
    │      └── DependencyX 1.x
    │
    └── PackageB
           └── DependencyX 2.x

Now you have a dependency conflict because PackageA and PackageB require different versions of the same dependency.

At this point, don't immediately install the newest version.

First determine whether newer versions of PackageA or PackageB are available that use compatible dependency versions.

---

🔄 Method 7: Check for Package Updates

In Visual Studio:

1. Right-click your project.
2. Select Manage NuGet Packages.
3. Open the Updates tab.
4. Check the packages involved in the dependency chain.

A newer version of the package causing the conflict may already have updated its dependency requirements.

Updating the parent package is often safer than manually forcing a dependency version.

---

🛠️ Method 8: Explicitly Reference the Dependency

Sometimes the NuGet error itself recommends explicitly referencing a dependency.

For example:

<PackageReference Include="DependencyX" Version="2.0.0" />

This can make the desired dependency version explicit for your project.

However, only do this when the selected version is compatible with the packages that depend on it.

---

🧹 Method 9: Restore Packages After Making Changes

After changing package versions, restore the project's packages:

dotnet restore

Then rebuild the project:

dotnet build

In Visual Studio, you can also use:

Build
→ Clean Solution

Build
→ Rebuild Solution

This ensures that the project is rebuilt using the updated dependency information.

---

🧪 Example: Finding the Problem Step by Step

Imagine Visual Studio reports a dependency conflict involving DependencyX.

Your project file contains:

<ItemGroup>
    <PackageReference Include="PackageA" Version="3.0.0" />
    <PackageReference Include="PackageB" Version="4.0.0" />
</ItemGroup>

You don't see DependencyX anywhere.

Run:

dotnet list package --include-transitive

You discover:

PackageA
    ↓
DependencyX 1.0.0

PackageB
    ↓
DependencyX 2.0.0

Now you know the conflict isn't directly caused by your project. It is caused by the dependency requirements of PackageA and PackageB.

You can then check whether a newer version of either package resolves the conflict.

---

❌ Don't Just Delete the Conflicting Package

A common mistake is to remove a package simply because it appears in the dependency conflict.

If another package depends on it, removing it may create additional compilation or runtime problems.

Instead, first determine:

• Which package introduced the dependency.
• Which version it requires.
• Which other package requires a different version.
• Whether compatible package updates are available.

---

❌ Don't Always Force the Newest Version

Installing the newest dependency version can sometimes remove a warning, but it can also introduce compatibility problems.

A package may have been designed and tested against a particular major version of its dependency.

Therefore, choose a version based on compatibility rather than simply choosing the highest available version.

---

📋 Quick Checklist

When you encounter a NuGet dependency conflict, follow this checklist:

1. Read the complete NuGet error message.
2. Identify the conflicting dependency.
3. Check your direct package references.
4. Run dotnet list package.
5. Run dotnet list package --include-transitive.
6. Find which package introduced the dependency.
7. Compare the required dependency versions.
8. Check for updates to the packages involved.
9. Explicitly reference a dependency only when appropriate.
10. Run dotnet restore.
11. Clean and rebuild the project.
12. Test the application.

---

🔗 Related NuGet Articles

Once you've identified the package causing the conflict, the next step depends on the specific NuGet error you're seeing.

📦 How to Fix NuGet Package Version Conflicts in Visual Studio

🔧 How to Fix NU1605: Package Downgrade Detected in Visual Studio

🔧 How to Fix NU1107: Version Conflict Detected for NuGet Package

---

🎯 Conclusion

Finding the NuGet package responsible for a dependency conflict becomes much easier once you understand the difference between direct and transitive dependencies.

Start with the complete Visual Studio error message, then use:

dotnet list package

and especially:

dotnet list package --include-transitive

to inspect the dependency tree.

Once you identify which package introduced the conflicting dependency, you can make an informed decision about updating the package, changing the dependency version, or explicitly referencing a compatible version.

🤖 AlgoLassi Assistant Have a question about this tutorial?

Ask AlgoLassi and get an answer plus the tutorials worth studying next.

Ask a question

💬 Comments

Sign in with Google to publish immediately, or comment anonymously and wait for approval.

Name Comment Post Comment

Comments will appear here when available.