dotnet-code-analysis

Configure built-in .NET SDK analyzers and gradually promote Roslyn warnings to build errors.

Updated Mar 31, 2026
One-click install
npx skills add https://github.com/zhenpengLai/myuseskill --skill dotnet-code-analysis-zhenpenglai
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dotnet-code-analysis
Source: https://github.com/zhenpengLai/myuseskill/tree/main/dotnet-code-analysis
Command: npx skills add https://github.com/zhenpengLai/myuseskill --skill dotnet-code-analysis-zhenpenglai

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Legacy .NET codebases often have hundreds of analyzer warnings, making it impossible to enable warnings-as-errors all at once. This Skill wires up first-party .NET SDK analyzers and applies a phased warning promotion strategy so CI can enforce code quality without flooding the build. ## Core Features & Use Cases - Analyzer Bootstrap: Enables EnableNETAnalyzers, AnalysisLevel, and AnalysisMode in Directory.Build.props with per-rule severity in a repo-root .editorconfig. - Gradual Warning Promotion: Batches legacy warnings by phase (trivial hygiene, code quality, security, full coverage) and promotes selected IDs via WarningsAsErrors after each batch is fixed. - Policy Guardrails: Hard rules prevent agents from disabling TreatWarningsAsErrors, adding NoWarn, or downgrading severity to make builds pass. - Use Case: A team with a legacy .NET solution wants CI to fail on analyzer warnings. The Skill counts warnings by ID, asks which batch to fix first, promotes those IDs to errors, and repeats until full coverage. ## Quick Start Ask the AI to enable built-in .NET analyzers and gradually promote Roslyn warnings to errors in this repository.

Frequently Asked Questions about dotnet-code-analysis

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enable built-in .NET code analyzers?▼

Set EnableNETAnalyzers to true and AnalysisLevel to latest-recommended in Directory.Build.props or your project file. For .NET 5 and later, analyzers ship with the SDK and are enabled by default, but explicit settings prevent accidental disabling.

How to treat specific Roslyn warnings as errors in .NET?▼

Add the diagnostic IDs to the WarningsAsErrors MSBuild property, for example WarningsAsErrors with CS8019;CS0219;CA2000. This selective approach is preferred over blanket TreatWarningsAsErrors for legacy codebases with many existing warnings.

What is the difference between AnalysisLevel and AnalysisMode?▼

AnalysisLevel selects which SDK rule set version applies, such as latest or latest-recommended. AnalysisMode controls how many rules are active: None, Default, Minimum, Recommended, or All. Combined syntax like latest-recommended sets both at once.

Should I use TreatWarningsAsErrors on a legacy .NET project?▼

No, blanket TreatWarningsAsErrors on legacy code produces hundreds of errors at once. Instead, count warnings by ID, fix them in batches starting with trivial hygiene rules like CS8019, and promote each fixed batch via WarningsAsErrors.

How do I set analyzer severity per rule in .NET?▼

Use a repo-root .editorconfig with entries like dotnet_diagnostic.CA2000.severity = error, or category-level settings such as dotnet_analyzer_diagnostic.category-Security.severity = error. Scope patterns let you relax rules for test or generated files.

When should I not use the built-in .NET analyzers alone?▼

Built-in SDK analyzers are not sufficient when you only need formatting, or when the project requires third-party or framework-specific analyzer packages beyond the SDK rule set. In those cases, add specialized analyzers on top of the SDK baseline.