Managing NuGet dependency conflicts in JetBrains Rider

Transitive NuGet conflicts in a .NET solution usually surface as build warnings or runtime behavior that does not match the version you explicitly referenced. Rider keeps the resolution work inside the IDE with a centralized NuGet tool window, a visual dependency graph, and an updates view that highlights drift.

The problem you see in practice

A project references Package A 2.0 which brings in Newtonsoft.Json 13.x transitively, while another project explicitly references Newtonsoft.Json 12.x. The .NET SDK resolves to the nearest version, but the mismatch is invisible until a test fails or a binding redirect is needed. In Rider, the NuGet tool window surfaces this as a conflict node in the dependency graph and flags outdated packages in the project explorer.

PackageReference is the modern SDK-style project format for declaring NuGet dependencies inside the .csproj file. packages.config is the legacy format used by older .NET Framework projects that stores dependencies in a separate file. Migration changes how transitive resolution is recorded and how Rider displays updates.

How Rider surfaces dependencies

Open the NuGet tool window via View | Tool Windows | NuGet. The window has Packages, Updates, and Dependency Graph tabs.

The Dependency Graph tab renders a visual graph of direct and transitive packages. Nodes show the resolved version and edges show which package brings a dependency in. Conflicts are highlighted so you can trace which project introduces a different version.

The Updates tab lists packages with newer versions available on the configured NuGet source. Rider integrates package search with summary and version history inline, reducing context switching to a browser.

Migrating packages.config to PackageReference

Rider supports automatic migration of packages.config to PackageReference for legacy projects. The migration rewrites dependency declarations into the .csproj and removes the packages.config file.

Run the migration from the NuGet tool window context menu on a project that still uses packages.config. Required permission is write access to the project folder. Expected check after migration is that the .csproj contains entries and packages.config is removed. Risk is that some older build targets or custom MSBuild logic that reads packages.config will break. Behavior varies between .NET Framework and .NET Core project systems regarding how dependencies are listed and restored.

Worked example: resolving a version conflict

Consider a solution with two projects, LibA and LibB, both consuming Newtonsoft.Json via different paths.

1. Open the solution in Rider and open the NuGet tool window.
2. Open the Dependency Graph tab and select the solution node. Identify the conflict node for Newtonsoft.Json showing two resolved versions.
3. Open the Packages tab for the project that should own the version, click Install or Update, and choose a single version to align both projects. Rider updates the .csproj automatically.
4. Verify the change by opening the .csproj file and confirming the entry reflects the chosen version. Run a restore via Rider Terminal with dotnet restore to ensure CLI consistency.

Rider integrates with the .NET CLI for restoration so the state matches CI/CD pipelines.

Trade-offs and limitations

Heavy use of the visual dependency graph in extremely large mono-repos can increase IDE memory consumption. For very large solutions, open the graph at the project level rather than solution level.

Updates are advisory. Applying an update via the UI changes project files. Keep changes under source control so you can revert if a breaking change appears.

Practical check: after any install or update, open the .csproj and confirm the PackageReference is present and the NuGet tool window no longer flags the package as outdated.

Actionable close

Use the Updates tab as a weekly hygiene check, resolve conflicts through the Dependency Graph before they reach CI, and migrate packages.config projects to PackageReference when you are ready to modernize the project system. Verify each change by inspecting the .csproj and running dotnet restore in the Rider Terminal.