Glossary / C# analyzers
C# analyzers
C# analyzers inspect source during development or compilation and report diagnostics about correctness, performance, security, API design, or style. Roslyn analyzers can run in IDEs and command-line builds, and code fixes may offer automated changes; they complement tests and reviews rather than proving correctness.
Diagnostics and configuration
A diagnostic has an identifier, severity, message, and source location. .NET analyzers include compiler and SDK rules; third-party analyzers add domain-specific checks. .editorconfig can set severity and options by rule, while project properties enable analysis levels and analysis modes. Code fixes are often exposed through IDE actions and can be applied in bulk, but semantic changes require review.
Analyzer versions and SDK defaults change. A clean build in one IDE does not guarantee CI uses the same analyzer set. Treat warnings as errors selectively and consistently; enabling thousands of legacy warnings at once can obscure high-value findings. Some analyzers require compilation context and may be expensive on large solutions.
Engineering guidance
Choose rules with strong signal for the codebase, pin versions, and enforce the same configuration in CI. Use baselines for legacy findings and ratchet toward stricter policy. Suppress with narrow scope and explanation. Review fixes and test generated or code-modified output.
Interview questions
- What is a Roslyn analyzer? A compiler-platform extension that inspects code/compilation and reports diagnostics.
- Do analyzers execute code paths? Usually no; they analyze syntax/semantic models, though rules can approximate behavior.
- What is a code fix? An IDE/build tooling action that transforms source to address a diagnostic.
- Why pin analyzer versions? Rule sets and behavior can change across releases.
- How adopt on legacy code? Baseline, prioritize, and ratchet severity gradually.