Repository navigation
Code fixes
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.
Getting started
Working with C#
Debugging and XAML
About