直接用sonarscanner for msbuild失败的根本原因是未在真实构建流程中注入分析逻辑，必须匹配msbuild版本、成对执行begin/end、确保roslyn分析器被编译器调用且规则手动激活。
为什么直接用 SonarScanner for MSBuild 会失败
多数人第一次集成时，在 Visual Studio 命令行里执行 SonarScanner.MSBuild.exe begin 就报错，常见现象是：项目无法加载、MSBuild 版本不匹配、或扫描后零指标。根本原因不是配置漏了，而是没意识到 SonarQube 对 MSBuild 生命周期的强依赖——它必须在真实构建流程中注入分析逻辑，而非独立运行。
- 必须使用与项目匹配的
MSBuild版本（.NET SDK 6+ 项目需用dotnet msbuild，非MSBuild.exe） -
begin和end必须成对出现在同一 shell 会话中，且中间只能调用一次dotnet build或msbuild - 若项目含
Directory.Build.props或自定义.targets，可能覆盖 SonarQube 注入的Import，导致分析器未激活
dotnet CLI 方式集成（推荐用于 .NET 5+）
绕过传统 MSBuild.exe 兼容问题，直接走 dotnet 工具链更稳定。前提是已安装 SonarScanner for .NET 全局工具：
dotnet tool install --global dotnet-sonarscanner
然后按顺序执行（注意路径和 token）：
dotnet-sonarscanner begin /k:"my-project-key" /o:"my-organization" /url:"https://sonarqube.example.com" /d:sonar.token="xxxxxx"
dotnet build MySolution.sln
dotnet-sonarscanner end /d:sonar.token="xxxxxx"
-
/k必须全小写，大小写敏感；/o仅限 SonarCloud 或启用了组织功能的 SonarQube 9.9+ - 若提示
Failed to resolve assembly Microsoft.CodeAnalysis，说明项目 SDK 版本太低，需升级到Microsoft.NET.Sdk并启用LangVersion10+ - 不建议在 CI 中用
--no-build，静态分析依赖编译生成的 PDB 和符号信息
如何让 SonarQube 识别 C# 代码规范规则（如 CA1707）
SonarQube 默认只启用基础规则集，Roslyn 分析器（如 Microsoft.CodeAnalysis.FxCopAnalyzers 或新式 Microsoft.CodeAnalysis.NetAnalyzers）需手动绑定。
- 在项目文件中显式添加
<packagereference></packagereference>，例如：<PackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="7.0.4" PrivateAssets="all" />
- 必须设置
<enablenetanalyzers>true</enablenetanalyzers>，否则即使包存在也不会触发分析 - SonarQube 界面中“Quality Profiles”→“.NET”→“Import from Roslyn analyzers”才能同步规则；导入后需点击“Activate”逐条启用（CA1707、CA1062 等默认不激活）
- 若看到
CS8032警告，说明分析器 DLL 被多个版本冲突加载，删掉bin/和obj/后重试
CI 环境下常见断点与绕过方式
GitHub Actions 或 Azure DevOps 中执行失败，90% 出现在 end 阶段找不到分析数据——因为工作目录切换、缓存干扰或并行构建污染了 .sonarqube 文件夹。
- 始终用绝对路径指定
/d:sonar.host.url和/d:sonar.token，避免环境变量未传递 - Azure Pipelines 中禁用
checkout: self的clean: true，否则.sonarqube被清空 - GitHub Actions 使用
actions/checkout@v4后，加一步run: rm -rf .sonarqube反而是安全的——因每次都是干净 workspace - 若项目含多个
.csproj但只希望扫描主项目，用/d:sonar.exclusions="**/Tests/**,**/*.Test.csproj"显式排除，别依赖默认过滤
真正卡住的地方往往不是怎么配，而是没意识到 SonarQube 的 C# 分析本质是“劫持 MSBuild 编译过程”。一旦构建命令没走它监控的那条路径，或者分析器没被编译器实际调用，所有配置都只是摆设。
