Different sonar scanner shows different LOC

SonarQube Server / Community Build
, ,
1

I am using SonarQube server Enterprise Edition v2026.1 (119033), deployed using a zip on Ubuntu 24.04.

I want to combine the analysis of C# code and C\C++ code. Initially, we used to have C++ analysis on a separate SQ project using the SonarScanner CLI with the buildWrapper, which covered all the required files, and the LOC was 177K.

To combine C++ with C#, I am using the MSBuild SonarScanner also with the buildwrapper for the C++ code, which shows fewer LOC(165K), and some important code files were skipped for some reason.

Sonar parameters I used with SonarScanner CLI version 7.0.2.4839:

“-Dsonar.projectKey=${getProjectName()}_cpp”,
“-Dsonar.sourceEncoding=UTF-8”,
“-Dsonar.buildString=${env.BUILD_NUMBER}”,
“-Dsonar.scm.provider=git”,
“-Dsonar.scm.revision=${BuildVariables.GIT_COMMIT_HASH}”,
“-Dsonar.projectBaseDir=${env.WORKSPACE}/${ArtifactsIn}”,
“-Dsonar.verbose=true”,
“-Dsonar.inclusions=**/*.cpp,**/*.h",
"-Dsonar.exclusions=**/coverage/**,**/UnitTests/**,**/.ci/**,**/BuildAgents/**,**/*.cs,**/*.html,**/*.Html”,
“-Dsonar.cfamily.compilecommands=${env.WORKSPACE}/${BuildWrapperOutputDirectory}/compile_commands.json”,
“-Dsonar.cfamily.cobertura.reportPaths=${cppCoveragePaths}”

Parameters I used with MSBUILD sonarscanner version 10.1.0.110937:

“/v:${BuildVariables.VERSION}”,“/k:${getProjectName()}”,“/n:${getProjectName()",
“/d:sonar.buildString=${env.BUILD_NUMBER}”,
‘/d:sonar.verbose=true’,
“/d:sonar.cs.vscoveragexml.reportsPaths=${codeCoverageResultsFilePath}”,
‘/d:sonar.sourceEncoding=UTF8’,
“/d:sonar.projectBaseDir=${env.WORKSPACE}/${ArtifactsIn}”,
“/d:sonar.exclusions=**/UnitTests/**,**/.ci/**,**/*.html”,
"/d:sonar.cfamily.compilecommands=${env.WORKSPACE}/${BuildWrapperOutputDirectory}/compile_commands.json”,
“/d:sonar.cfamily.cobertura.reportPaths=${cppCoveragePaths}”,

I also tried to use compile_commands with variants by compiling each platform, and used the following parameters, but got the same result:

SonarScanner.MSBuild.exe begin 
    & $Arguments.BuildWrapperExecutablePath --out-dir "$($buildWrapperOutputDirectory)\x86" $msbuildPath $projectPath /P:Configuration=Release /P:Platform="x86" /t:Rebuild /nodeReuse:False /m
    & $Arguments.BuildWrapperExecutablePath --out-dir "$($buildWrapperOutputDirectory)\x64" $msbuildPath $projectPath /P:Configuration=Release /P:Platform="x64" /t:Rebuild /nodeReuse:False /m
SonarScanner.MSBuild.exe end

'/d:sonar.cfamily.variants.names=x86,x64',
"/d:sonar.cfamily.variants.dir=${env.WORKSPACE}/${ArtifactsIn}/${BuildWrapperOutputDirectory}"

My Question is, do different scanners have different results? And how can I get a complete analysis for my C++ code when I combine it with C#?

2

Hello @Ahmed_Ghareeb,

Is the C++ code part of the Visual Studio solution/sub-project structure? Or are they dangling in some shared folder? This is a warning that we mention in the docs which cover the analysis of C++ code with the SonarScanner for .NET. The SonarScanner for CLI will analyze whatever you tell it to, but the SonarScanner for .NET derives the analysis scope from the Visual Studio solution and project files. This could explain the difference.

Oh and also to clarify: which files are being ignored? Are they the C++ files? Are they all in a particular sub-project?

3

Hi @andres ,
Thank you for the response. I checked the solution thoroughly, and I find that there are some analyses missing from for C++ files that are part of a C++ vcxproj. Similarly there’s analysis missing for C# files as well which are part of a C# csproj.

4

Hi @Ahmed_Ghareeb, and for those files missing analysis, is it the whole sub-project that is missing it? Or are other files in the same sub-project analyzed correctly?

Regardless, I would say we have 2 options to be able to investigate in depth:

  • Boil your project down to a minimal reproducer that you can share. I imagine your project is big so it won’t be easy. But what I’m proposing is, if you could remove most of the actual content in the sub-projects but preserve the project structure, and preserve dummy versions of the files that should be analyzed but aren’t.
  • Share debug-level logs with us. Probably you would have to redact stuff. If you share this, please share also some file names that are affected.