Use Build.BuildId instead of Build.BuildNumber

  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting)


and here

you are using the build.BuildNumber variable of ado pipeline.

Instead, I would advice to use Build.BuildId. The buildnumber is the title of a pipeline and can contain various unusual characters, e.g. slash, back-slash, Unicode Chars and so forth, that are not suitable for files names or folder names. With the buildId you would get a much stabler ado experience.

  • Potential workaround

As a workaround I currently use the logging function of ADO (build.updatebuildnumber) to change the buildnumber to buildId before calling sonar.

Changing sonar.scanner.metadataFilePath is not sufficient, because the publish task has hard coded demands, again with build.BuildNumber.

Please fix, Cheers, Andreas

1 Like

Hi. I confirm there is a bug in the extension.

The standard way of running sonarqube for msbuild is:

  1. run sonarqube prepare task
  2. dotnet/msbuild build
  3. run code analysis task
  4. run sonarqube publish task

On step 1, the prepare task is creating a report file using the Build.BuildNumber in the file path.
In our build, we are using a package which defines the new version, and set the new Build.BuildNumber … on step 2.
Which lead to the bug, because on step 4, the publish task does not found the report file, because the Build.BuildNumber has changed.

To summarize: anytime the Build.BuildNumber is changed after you’ve run the Sonarqube prepare, then the report file will not be found.

This indeed need a fix.

Hi there,

Thanks for raising this. It has been added to our backlog internally and we will discuss it, since we do not consider this as a blocker for now. Unfortunately, we don’t have any ETA to give you on this.


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