Perpare@7 not allowing msbuild as scannermode

Moved to the correct spot for replying
I noticed that when I started using @7, my code coverage dropped to zero and the number of files to cover dropped by ~190K files. My new prepare task is

    - task: SonarQubePrepare@7
      inputs:
        SonarQube: 'Sonarqube - OnPremises'
        scannerMode: 'dotnet'
        projectKey: '***'
        projectName: '***'
        projectVersion: '$(Build.BuildNumber)'
        extraProperties: |
          'sonar.cs.dotcover.reportsPaths="c:\sonarqube\output_trunk\***.html"'
          sonar.scanner.scanAll=false

My old task is

    - task: SonarQubePrepare@6
      inputs:
        SonarQube: 'Sonarqube - OnPremises'
        scannerMode: 'MSBuild'
        projectKey: '**'
        projectName: '**'
        projectVersion: '$(Build.BuildNumber)'
        extraProperties: 'sonar.cs.dotcover.reportsPaths="c:\sonarqube\output_trunk\**.html"'

I was forced to use dotnet in @7, from msbuild. Could this be the issue and if so, why are we forced to do this if @6 is being deprecated in the future?

1 Like

I rolled our nightly back to use the @6, which supports the msbuild scanner type and we are back to seeing code coverage and lines of code that are more accurate. Any insight on this would be great, as it is preventing us from upgrading to the @7 version

Hi @Devin_Quince, thanks for raising this issue.

I was forced to use dotnet in @7, from msbuild. Could this be the issue and if so, why are we forced to do this if @6 is being deprecated in the future?

No. I think the issue must be elsewhere. Could you please share the logs for the SonarQubePrepare and SonarCloudAnalyze@3 steps in verbose mode?

You can activate verbose mode by adding sonar.verbose=true in the extraProperties section.

I am not authorized to post our logs in a public forum, but all I know is if I only change from the @6 to the @7 as posted above, my code coverage stops working. Is there a reason the MSBuild scanner type is no longer supported in the @7 task version? Also, we never used the @3 version, this from @6 to @7.

Hi Devin,

I am not authorized to post our logs in a public forum

I understand. If the problem persists and you need further help, let me know so I can open a private thread.

In case you have support included in your subscription, please contact the support team.

In any case, you can also remove the private information from the logs.

all I know is if I only change from the @6 to the @7 as posted above, my code coverage stops working

The extension itself is just a wrapper for the scanner. It downloads and runs the right scanner based on the environment and the parameters provided.

The v6 version of the extension embeds an older version of the Scanner for .NET (6.2.0.85879) while the v7 embeds 9.0.0.100868.

Using the msBuildVersion: '<scanner-version>' parameter you can customize the version of the scanner used. For example, you can use the latest version of the Azure DevOps extension with an older version of the scanner.

The problem you’re facing seems to be a regression in one of the new Scanner versions.

Is there a reason the MSBuild scanner type is no longer supported in the @7 task version?

The value was just renamed from MSBuild to dotnet. The actual difference consists only of the default scanner version that is embedded in the task, as explained above.

Also, we never used the @3 version, this from @6 to @7.

My bad, I wrote by mistake the latest version of the SonarCloud extension when I actually wanted to mention SonarQubeAnalyze@7

1 Like

Thanks, I tried privatizing our log, but our infosec did not approve the log. I will ask about a private thread with my manager, as we do not have support that I know of.
Ok, I understand the scannermode I think, but by this statement, do you mean this might be causing the loss of code coverage with the new task?
The problem you’re facing seems to be a regression in one of the new Scanner versions.
Thanks

1 Like

do you mean this might be causing the loss of code coverage with the new task?

Starting with Scanner for .NET v8, we changed the way the project base directory is automatically detected. Since the source files are resolved relative to sonar.projectBaseDir, the paths from the coverage file might not match, resulting in a loss of coverage.

When verbose mode is enabled, the Analyze task (END step of the Scanner) will print some values like:

sonar.projectKey=<project-key>
sonar.working.directory=/home/vsts/work/1/.sonarqube/out/.sonar
sonar.projectBaseDir=/home/vsts/work/1/s
sonar.pullrequest.cache.basepath=/home/vsts/work/1/s
sonar.sources=\
"/home/vsts/work/1/s/scanner/SonarScanner.MSBuild.runtimeconfig.json",\

If the value for sonar.projectBaseDir is different between your runs (@6 vs @7), it might be the source of the issue. You can also check in the logs if there are mentions of the coverage computation. That can bring some clues as well.