.NET Code Analysis

Trigger On

• the repo wants first-party .NET analyzers
• CI should fail on analyzer warnings
• the team needs AnalysisLevel or AnalysisMode guidance
• the repo needs a gradual Roslyn warning promotion strategy

Workflow

flowchart TD
    A[Start] --> B{New or legacy project?}
    B -->|New| C[TreatWarningsAsErrors=true immediately]
    B -->|Legacy| D[dotnet build, count warnings by ID]
    D --> E{"< 30 warnings?"}
    E -->|Yes| F[Fix all, then enable TreatWarningsAsErrors]
    E -->|No| G[Report counts to user, ask which batch first]
    G --> H[Add selected IDs to WarningsAsErrors]
    H --> I[Fix that batch, verify build]
    I --> J{More batches?}
    J -->|Yes| G
    J -->|No| F
    C --> K[Set AnalysisLevel latest-recommended]
    F --> K
    K --> L[Promote security CA3xxx/CA5xxx to error in .editorconfig]
    L --> M[Validate: build + CI green]

1. Start with SDK analyzers before third-party packages.
2. Detect project maturity: new or existing/legacy.
3. Enable EnableNETAnalyzers, AnalysisLevel, AnalysisMode in Directory.Build.props.
4. Apply the right warning promotion strategy (see below).
5. Per-rule severity goes in repo-root .editorconfig.
6. dotnet build is the analyzer gate in CI.

Deliver

• explicit, reviewable first-party analyzer policy
• build-time analyzer execution for CI
• warning promotion plan matching project maturity

Validate

• analyzer behavior driven by repo config, not IDE defaults
• CI reproduces same warnings/errors locally
• no TreatWarningsAsErrors, WarningsAsErrors, or severity settings removed/weakened without user approval
• promoted warnings produce build errors, not just IDE hints

Load References

Related skills

Related agents