.NET Core项目SonarQube命令行正常但Jenkins执行失败

这种手动执行正常但Jenkins跑就出问题的情况，十有八九是执行环境不一致或者Jenkins的执行上下文有差异导致的，我帮你梳理几个最可能的排查方向和解决办法：

1. 先确认构建命令是否真的执行成功了 #

SonarQube的报错核心提示是“项目未构建”，所以第一步要在Jenkins的构建日志里，仔细查看begin和end步骤之间的构建命令（比如dotnet build）有没有完整执行并输出“构建成功”的日志。

• 如果构建命令失败了，先解决构建本身的问题（比如依赖缺失、路径错误），SonarQube才能正常收集信息。
• 可以给构建命令加上详细日志参数：dotnet build YourSolution.sln -c Release -v detailed，方便定位构建失败的具体原因。

2. 检查Jenkins的环境变量是否和手动执行一致 #

手动执行时你用的是当前登录用户的环境变量，但Jenkins通常以Local System或者特定服务用户运行，这个用户的环境变量可能没包含.NET Core 2.0 SDK的路径：

• 在Jenkins构建步骤里先加一条命令：dotnet --version，看看输出的版本是不是你手动使用的.NET Core 2.0版本。
• 如果版本不对，需要在Jenkins的全局工具配置里添加对应的.NET Core 2.0 SDK，或者在构建脚本里手动指定SDK的路径（比如set PATH=C:\Program Files\dotnet\;%PATH%）。

3. 确保Jenkins的工作目录和手动执行的上下文一致 #

手动执行时你可能是进入到解决方案所在的子目录运行脚本，但Jenkins默认的工作目录是job的根目录，相对路径错误会导致找不到解决方案文件：

• 在脚本开头加上切换目录的命令，比如：cd %WORKSPACE%\YourSolutionSubDir（Windows环境用%WORKSPACE%变量），或者直接用绝对路径指定解决方案文件。

4. 排查权限问题 #

Jenkins运行的用户可能对工作区的文件/目录没有足够的读写权限，导致构建生成的bin、obj目录无法被SonarQube读取：

• 尝试给Jenkins运行用户（比如Local System）赋予Jenkins工作区目录的完全控制权限。
• 可以在构建前添加“删除工作区”的步骤，清理旧的文件和权限残留，再重新构建。

5. 严格遵循SonarQube MSBuild的执行顺序 #

确保脚本的执行顺序绝对正确：

# 1. SonarQube begin步骤（可加verbose参数开启详细日志）
SonarScanner.MSBuild.exe begin /k:"你的项目Key" /n:"你的项目名称" /v:"版本号" /d:sonar.verbose=true

# 2. 执行构建命令（必须成功完成）
dotnet build YourSolution.sln -c Release

# 3. SonarQube end步骤
SonarScanner.MSBuild.exe end

• 中间不能省略构建步骤，也不能把构建命令和begin/end步骤混写，避免Jenkins解析命令时出错。

6. 开启SonarQube详细日志排查 #

在begin步骤添加/d:sonar.verbose=true参数，这样SonarQube会输出更详细的日志，你可以从日志里看到它在收集哪些文件、有没有找不到文件的错误，从而精准定位问题。

内容的提问来源于stack exchange，提问作者Greg