"build-wrapper-dump.json" file was found but 0 C/C++ when removing a project from my analysis

In Azure Devops, the sonar analysis runs well.
I have different C++ projects and use the last build-wrapper-win-x86-64.exe to analyse them.

It works well BUT I just removed a not useful anymore project and all the associated sources… And the corresponding PR failed with this strange error:

INFO: Sensor CFamily [cpp]

INFO: CFamily plugin version: 6.52.0.66181

INFO: Using build-wrapper output: D:\DevOps_build_agent\_work\1\s\mvt_build_wrapper_output_directory\build-wrapper-dump.json

INFO: Available processors: 6

INFO: Using 6 threads for analysis.

INFO: Loading cache from: server

INFO: PCH: unique=0 use=0 (forceInclude=0,throughHeader=0,firstInclude=0) out of 0 (forceInclude=0,throughHeader=0)

INFO: Z3 refutation rate: 0 out of 0

INFO: SE: 0 out of 0

INFO: Subprocess(es) done in 85ms

INFO: 485/624 files marked as unchanged

INFO: Cache: 0/0 hits, 125 bytes

INFO: 0 compilation units analyzed

INFO: ------------------------------------------------------------------------

INFO: EXECUTION FAILURE

INFO: ------------------------------------------------------------------------

INFO: Total time: 38.673s

INFO: Final Memory: 42M/320M

INFO: ------------------------------------------------------------------------

##[error]ERROR: Error during SonarScanner execution

ERROR: Error during SonarScanner execution

##[error]java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found but 0 C/C++/Objective-C files were analyzed. 

That I could not understand, I only remove one project the rest is still compiled and I can see a lot of Sonar log during build like:

       SonarCategoriseProject:
         Sonar: (rx_tif_lib.vcxproj) Categorizing project as test or product code...
         Unable to parse assembly name '@()'
         Sonar: (rx_tif_lib.vcxproj) categorized as MAIN project (production code).
       SonarCreateProjectSpecificDirs:
         Creating directory "D:\DevOps_build_agent\_work\1\.sonarqube\conf\5".
       SonarWriteFilesToAnalyze:
         Sonar: (rx_tif_lib.vcxproj) Number of files to analyse: 4. The list of files to be analyzed is in D:\DevOps_build_agent\_work\1\.sonarqube\conf\5\FilesToAnalyze.txt.
       SonarWriteProjectData:
         Sonar: (rx_tif_lib.vcxproj) Project processed successfully

What can I check here…
I retrieve both build-wrapper-dump.json but it not simple to analyse as none of them seems to contains all .c/cpp files…

Could you help me on this strange issue… Where could I find the list of files it is supposed to analyse and WHY removing one projects from more than 10 c++ projects gives such error?

Regards

Thanks

Finally I find it with the help of the documentation:
C/C++/Objective-C (sonarsource.com)

Just add the /nodeReuse:false

So I just discover that my Sonar analysis is only partial :frowning: because I do not remenber to read this when I make my Sonar project few years ago…

Is it a new issue with MsBuild?

Hi @Laurent,

We added the recommendation of using /nodeReuse:false ~2 years ago: https://sonarsource.atlassian.net/browse/CPP-3636

The requirement to provide a build wrapper a command that starts a clean full build was always there.
If nodes are reused, build-wrapper will be unable to detect the build command that and hence not analyze the file compiled using the reused node.

What makes this problem more challenging to spot is the undeterminism of node reuse. It depends on your CI pipeline structure and duration. Hence, a file might be analyzed on one run (when nodes aren’t reused) and skipped on others(when nodes aren’t reused). That is why we decided to document that msbuild option explicitly.

It seemed that by removing the project, you hit a case where nodes are reused for all files => no compilation commands are detected by build-wrapper => nothing is analyzed => hard failure.

Sorry for wasting your time discovering this argument, and I hope that the new analysis results make more sense.

Thanks,

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.