Rider Solution-Wide Analysis: Catching Cross-Project Breaks Before Commit

The real problem with per-file analysis in .NET is that it is locally correct and globally blind. You can refactor a public API in a core library, get green squiggles in that project, and still break three downstream services that reference it. Solution-Wide Analysis in JetBrains Rider changes the unit of analysis from the open file or project to the whole solution graph.

The thesis is simple: correctness and completeness across project boundaries is worth background resource cost. Rider accepts higher memory and CPU use to keep a consistent inspection state for the entire solution, so cross-project misuse surfaces before build or commit.

From project-local to solution-wide inspections

Traditionally Rider, like many IDEs, runs ReSharper-based inspections per project as files are opened. That is fast and responsive, but it misses patterns that only exist across references. Dead code in a library may be used in another project. Unused usings can be hidden by conditional compilation. Nullability mismatches only become visible when a producer and consumer are analyzed together.

Solution-Wide Analysis runs the same inspection engine across the entire solution graph. The graph includes class library projects, test projects, and web apps linked by project references. Inspections such as obsolete member usage, API misuse, and potential null dereference are evaluated with full reference information, not just the symbols visible in the current project.

This is an engineering decision to prioritize a consistent analysis state over immediate responsiveness. The IDE trades initial indexing latency and background CPU for fewer surprises later.

Practical setup and how to verify it is working

Solution-Wide Analysis is an IDE inspection setting, not a build setting. It is advisory and complements the compiler and Roslyn analyzers.

To check availability, open Rider Settings and navigate to Editor | Inspection Settings. The Solution-Wide Analysis toggle and scope options are located there. The scope controls whether analysis runs for the whole solution or is limited to projects with open files.

On a multi-project .NET solution, opening Rider shows a background progress indicator for solution analysis. Completion time varies with solution size, project types, installed SDKs, and the number of external NuGet packages. Machines with limited RAM may see noticeable IDE slowdown while the initial analysis completes.

A practical verification is to introduce a deliberate cross-project change. Mark a public method in a core library as obsolete with a message, then open the solution. With Solution-Wide Analysis enabled, warnings about obsolete usage should appear in consuming projects even if those projects are not open in the editor. Compare those IDE inspections with a clean build to see differences between IDE analysis and compiler diagnostics.

Worked example: obsolete API in a shared library

Consider a solution with CoreLib and WebApp, where WebApp references CoreLib. CoreLib exposes a public method ProcessOrder that is used in several call sites in WebApp.

With Solution-Wide Analysis enabled, changing the signature or marking ProcessOrder as obsolete in CoreLib causes Rider to surface the impact across the solution graph. You would expect obsolete member warnings in WebApp call sites, and potential nullability mismatch hints if the new signature changes nullable annotations. No manual search across projects is required for the IDE to flag the affected consumers.

This example illustrates the value proposition: breaking changes in shared libraries are surfaced as inspection results in downstream projects before a build is run.

Trade-offs and limitations

Solution-Wide Analysis increases memory footprint and background CPU usage. Initial indexing latency grows with solution size, and solutions with many external NuGet packages increase indexing time and background activity.

Inspections are advisory. They may differ from compiler or Roslyn analyzer output, and they should not replace builds and CI checks. Behavior and performance are version sensitive and depend on solution size, project types, and installed SDKs.

For large monorepos or constrained machines, you may want to limit the scope to specific projects or disable Solution-Wide Analysis during heavy editing sessions.

Actionable closing

Enable Solution-Wide Analysis for solutions where cross-project API stability matters, verify it is running by watching the background analysis indicator and checking that cross-project warnings appear without opening every consumer, and keep builds and CI as the source of truth for correctness. Use the setting deliberately, not as a default for every solution.