Skip to content

Code fixes

Steven Blom edited this page Sep 12, 2026 · 1 revision

Fixing what the analyzers report

rose_list_code_fixes says what can be fixed in a file; rose_apply_code_fix applies it to that file, its project, or the whole solution through Roslyn's own fix-all.

No dependency was added for this. Analyzers ship their fixers in the same assemblies, so a solution that reports a diagnostic already carries the code that repairs it — measured at 206 fix providers over 186 diagnostic ids for this repository and 143 over 120 for a Revit add-in, entirely from packages those solutions already referenced. Roslyn exposes the analyzers through AnalyzerReference but not the fixers, so those are found by reflecting over the same assembly — loaded through the shadow-copy loader, never from AnalyzerReference.FullPath, which is deliberately still the original file.

Only the analyzers that report the requested id are run. A full analyzer pass over a large project is seconds to minutes; fixing one rule is a fraction of that, for the same answer.

The IDE catalogue is included, and needed no package either. The SDK ships Microsoft.CodeAnalysis.CSharp.CodeStyle.Fixes.dll beside its code-style analyzers and passes both to the build, so a project that sets EnforceCodeStyleInBuild already has all 140 of those fixers on disk. Reaching them takes one thing: when GetTypes throws because a single type in an assembly will not load, salvage the ones that did rather than discarding the assembly. That turned 186 fixable ids into 433 for this repository — 112 IDE*, and 119 compiler CS* fixes, which are the "add the missing using" and "remove the unreachable code" an editor offers on a red squiggle.

A project that does not turn code style on in the build has the CA rules and no IDE ones, because the fixers follow the analyzers. That is visible rather than silent: rose_list_code_fixes reports the ids it found no fix for.

Clone this wiki locally