如何让.editorconfig真正影响Roslyn分析器行为
Roslyn不会自动读取
.editorconfig中的分析器规则配置——它只认其中以
dotnet_diagnostic.开头的键，且仅限于内置诊断ID（如
CA1822、
IDEX001）或你显式注册过的自定义诊断ID。 常见错误现象：
.editorconfig里写了
dotnet_diagnostic.CA1822.severity = warning，但项目里仍不报 CA1822；原因通常是没引用
Microsoft.CodeAnalysis.FxCopAnalyzers（旧包）或
Microsoft.CodeAnalysis.NetAnalyzers（新包） 使用场景：你想统一团队对命名、性能、设计规则的严重级别，而不是靠每个项目手动改
.ruleset必须确保分析器 NuGet 包已安装且版本兼容：.NET 5+ 推荐用
Microsoft.CodeAnalysis.NetAnalyzersv7+；老项目若还在用
FxCopAnalyzers，
.editorconfig的诊断ID前缀可能不匹配
.editorconfig中的
severity设置优先级高于
.ruleset，但低于项目文件里的
<nowarn></nowarn>或源码中的
#pragma warning
.ruleset 文件里哪些设置会被 Roslyn 实际读取
Roslyn 只解析
.ruleset中的
<rule></rule>节点里的
Id和
Action字段，其他字段（如
Justification、
Tool）被完全忽略。 常见错误现象：在
.ruleset里把
Action写成
Warning（首字母大写），实际必须是全小写
warning；否则该规则默认按
None处理，等于关闭 参数差异：
Action可选值只有
None、
Warning、
Error、
Info（注意大小写敏感），且
Info在 VS 中默认不显示，需开启“显示信息级消息”选项 性能影响：启用大量规则（尤其数据流类如
CA2007、
CA2016）会显著拖慢增量编译；建议在 CI 中启用全部，在本地开发时用
.editorconfig临时降级部分规则 路径必须被项目引用：在
.csproj中需显式指定
<codeanalysisruleset>MyRules.ruleset</codeanalysisruleset>，否则文件存在也无效
自定义 Roslyn 分析器的规则怎么进.editorconfig
你的自定义分析器生成的诊断ID（如
MY001）要出现在
.editorconfig中，前提是它已被 Roslyn 识别为“已知诊断”，而这依赖于分析器 DLL 是否正确导出
DiagnosticDescriptor并注册到编译器上下文。 容易踩的坑：分析器项目未在
AnalyzerReleases.Unshipped.md或
SupportedDiagnostics属性中声明 ID，导致
.editorconfig解析时静默跳过该行 验证方法：编译后打开生成的
.dll，用
ildasm查看
Microsoft.CodeAnalysis.Diagnostics.AnalyzerConfigOptionsProvider是否存在，或运行
dotnet build /bl后用
MSBuild Structured Log Viewer检查是否加载了你的分析器 必须在
.editorconfig中使用完整 ID：例如
dotnet_diagnostic.MY001.severity = error，不能省略
dotnet_diagnostic.前缀，也不能写成
my001（大小写必须完全一致） 如果分析器带多个类别（如
MY001、
MY002），建议在
.editorconfig中按组设置：
dotnet_diagnostic.MY.severity = warning（前提是分析器代码中设置了
CustomTags并在
AnalyzerConfigOptions中支持通配）
VS 和 dotnet CLI 对.editorconfig/.ruleset 的行为差异
Visual Studio 默认启用实时分析（Live Analysis），而
dotnet build默认只跑编译期分析（Compile-Time Analysis）；这意味着同一套配置在两个环境里可能表现不一致。 常见错误现象：VS 里看到警告，但
dotnet build不报；通常是因为 VS 加载了额外的后台分析器（如
Microsoft.VisualStudio.Threading.Analyzers），而 CLI 没装对应扩展 兼容性关键点：
.ruleset在 CLI 中完全生效，但
.editorconfig的
dotnet_diagnostic.*配置在
dotnet build中要求 SDK 版本 ≥ 5.0.200，且项目 SDK 类型必须是
Microsoft.NET.Sdk（不是
Microsoft.NET.Sdk.Web等派生 SDK 的旧版本） 调试建议：加
/v:detailed参数运行
dotnet build，搜索日志中是否出现
Applying editorconfig file或
Loading ruleset；没出现说明路径不对或格式非法 一个硬限制：VS 的“错误列表”窗口会合并
.ruleset和
.editorconfig的结果，但 CLI 输出只反映编译器最终采纳的 severity——所以别依赖 VS 界面判断 CI 行为
最常被忽略的是分析器包与 SDK 版本的隐式绑定关系：.NET 6 SDK 自带 NetAnalyzers v6，但如果你手动引用 v7 包，又没同步更新
<enablenetanalyzers>true</enablenetanalyzers>，.editorconfig 里的配置就根本不会被扫描到。
