dotnet-analyzer-config

Configures .NET analyzer and code-style rules through a repo-root .editorconfig file.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? .NET repositories often have analyzer severity and code-style rules scattered across IDE settings, MSBuild files, and ad-hoc configs, making rule ownership unclear and builds inconsistent between local and CI environments. This Skill establishes a single repo-root .editorconfig as the explicit source of truth for analyzer and style configuration. ## Core Features & Use Cases - Root .editorconfig authoring: Creates or normalizes a lowercase .editorconfig with root = true, correct EditorConfig syntax, forward-slash globs, and no inline comments. - Rule severity management: Moves dotnet_diagnostic.* severities into .editorconfig while keeping bulk switches like EnableNETAnalyzers in MSBuild files, with nested .editorconfig files for scoped subtrees such as tests, legacy code, or generated code. - Ready-made references: Ships a full template, a minimal template, and a catalog of CA, SA, and RCS rule severities organized by category. - Use Case: A team inherits a .NET repo where analyzer warnings appear in the IDE but not in CI. Use this Skill to consolidate all severity rules into one versioned root .editorconfig, verify with dotnet build, and return a structured status report. ## Quick Start Ask the agent to make .editorconfig the source of truth for analyzer rules in this .NET repository and verify the result with a build.

Frequently Asked Questions about dotnet-analyzer-config

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

FAQPage Schema
How do I configure .NET analyzer rules in .editorconfig?▼

Set rule severity with `dotnet_diagnostic.<RULE_ID>.severity` entries under a `[*.cs]` section in a repo-root `.editorconfig` containing `root = true`. Both `dotnet format` and .NET analyzers read this file during local and CI builds.

What is the difference between .editorconfig and .globalconfig for analyzers?▼

`.editorconfig` uses file-tree inheritance from the repo root and is the recommended default for normal .NET repos. `.globalconfig` is an exceptional case for analyzer config distributed by packages or SDK conventions where file-tree inheritance does not fit.

Should analyzer settings go in .editorconfig or MSBuild files?▼

Rule severities belong in `.editorconfig`, while bulk switches like `EnableNETAnalyzers`, `AnalysisLevel`, and `AnalysisMode` belong in project files or `Directory.Build.props`. This keeps one clear ownership model per concern.

Can I use nested .editorconfig files in a .NET repo?▼

Yes, nested `.editorconfig` files are appropriate when a subtree has a clear scoped purpose, such as relaxed rules for generated code, different test conventions, or stricter rules in a core domain. Closer files override parent rules for matching sections.

Why are my .editorconfig analyzer rules being ignored?▼

Common causes include missing `root = true`, inline comments which the EditorConfig spec does not support, backslashes instead of forward slashes in globs, or IDE-only settings silently overriding repo policy. Verify with `dotnet build` that severities reproduce in CI.

When should I not use a root .editorconfig for analyzer config?▼

Avoid it when the repo intentionally stores analyzer policy only in IDE profiles or ephemeral local settings, or when choosing analyzers without any config change. It is also unnecessary for formatting-only work with no rule ownership question.