Rider Solution-Wide Analysis for Large .NET Codebases

Ghost methods in a 500-project solution

File-level analysis in Rider can see a single file, but it cannot tell you if a public method in Project A is used anywhere else, or if an interface defined in Project Z is actually implemented. In a large .NET solution that gap hides dead code and missing implementations until a build breaks.

Solution-Wide Analysis builds a whole-solution model in the background. The useful takeaway is to enable it selectively for refactoring and disable it for heavy debugging, with scopes and exclusions to keep memory use manageable.

How SWA differs from file-level analysis

File-level analysis understands context inside the open file. SWA understands cross-file and cross-project relationships.

• Unused public members across project boundaries
• Missing interface implementations
• Inconsistent naming across projects
• Dead code never referenced

When active, the Errors in Solution tool window shows a live count of solution-wide issues. Double-clicking an entry navigates across project boundaries, and Alt+Enter offers Fix All in Solution for bulk corrections.

Performance trade-offs and configuration

SWA is off by default for new solutions because it consumes significant memory and CPU on large codebases. JetBrains recommends enabling it selectively via the status-bar toggle or Settings → Editor → Inspection Settings → Enable Solution-Wide Analysis.

Key tuning knobs include:

• Scope limiting: right-click solution → Scope to analyze only specific projects
• Generated code exclusion: Settings → Editor → File Types → Ignored Files to skip .g.cs and obj folders
• Thread priority: rider64.exe.vmoptions with -Didea.analyzer.thread.priority=LOW
• Incremental caching: Rider 2024.2+ persists the model to disk at ~/.config/JetBrains/Rider2024.2/solution-caches

Memory footprint scales non-linearly. Solutions with more than 1,000 projects may exceed 4 GB heap even with exclusions.

Practical workflow for refactoring

Enable SWA before a refactoring sprint using the status-bar toggle. Run Code Cleanup with the Solution-Wide profile to apply style fixes across the solution. Disable SWA during heavy debugging sessions to reclaim heap.

The persistent cache can grow to several GB. Clean it via File → Invalidate Caches → Solution-Wide Analysis caches when disk space is constrained.

Worked example: unused public member across projects

1. Create a public class in Project A with a public method that is not referenced.
2. Enable Solution-Wide Analysis via the bottom-right status bar.
3. Open Errors in Solution. The UnusedMember.Global inspection appears for the method even though the usage check crosses project boundaries.

Heap change can be observed via Help → Diagnostic Tools → Memory Indicator. Expect an increase in the range of +500 MB to 2 GB depending on solution size.

Limitations and false positives

SWA can produce false positives on reflection-heavy code such as ASP.NET Core DI registrations and Entity Framework model builders. Suppress with // ReSharper disable once UnusedMember.Global or lower severity in .editorconfig with resharper_unused_member_global_severity = hint.

Hot Reload and Edit-and-Continue pause SWA updates. The Errors in Solution count may stale until the debug session ends or you trigger Reanalyze Solution with Ctrl+Shift+Alt+R.

Team-shared .idea/inspectionProfiles/Project_Default.xml stores the SWA enable state. Committing it forces the setting on all Rider users.

Actionable closing

Use SWA selectively, limit scope and exclude generated code, rely on incremental caching for faster reloads, and document the shared inspection profile in CONTRIBUTING.md. For very large solutions, consider splitting solutions or using Analyze Only Open Files mode.