Scanning Service Fabric solutions in Azure DevOps

SonarQube Server / Community Build
, ,
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension): Enterprise Edition Version 8.9.7 (build 52159)
  • what are you trying to achieve: analysis of .NET Core services in a Service Fabric solution
  • what have you tried so far to achieve this: using SonarQube tasks in yaml pipeline:
 - task: SonarQubePrepare@5
    condition: and(succeeded(), ne('${{ parameters.sonarQubeProject }}', ''))
    inputs:
      SonarQube: ${{parameters.sonarQubeConnection}}
      scannerMode: 'MSBuild'
      projectKey: ${{parameters.sonarQubeProject}}
      # RE sonar.exclusions: we rely on the solution and the SF project having the same name, don't @ me
      extraProperties: |
        sonar.sources=src/${{parameters.serviceFabricFolderName}}

- task: DotNetCoreCLI@2
    displayName: 'dotnet restore'
    inputs:
      command: 'restore'
      projects: '${{ parameters.serviceFabricSolution }}'
      feedsToUse: 'config'
      nugetConfigPath: 'NuGet.config'
      verbosityRestore: 'normal'
  - task: DotNetCoreCLI@2
    displayName: 'dotnet build --no-restore'
    inputs:
      command: 'build'
      projects: '${{ parameters.serviceFabricSolution }}'
      arguments: '-c Release --no-restore -v d'
  - task: SonarQubeAnalyze@5
    condition: and(succeeded(), ne('${{ parameters.sonarQubeProject }}', ''))
    env:
      SONAR_DOTNET_ENABLE_CONCURRENT_EXECUTION: true
  - task: SonarQubePublish@5
    condition: and(succeeded(), ne('${{ parameters.sonarQubeProject }}', ''))
    inputs:
      pollingTimeoutSec: '300'

Firstly I’m not entirely sure how the analyzer is determining what files to scan, unless it detects it from the dotnet restore task. The dotnet build task actually doesn’t build anything with our current solution configuration, because the projects that contain actual code are not set to build in release mode (I am not sure why this is the case, but if I configure them to build in release mode, the analyzer picks up every single source file as a duplicate).

Secondly, I’m seeing this in the logs of the analyzer:

INFO: ------------- Run sensors on project
INFO: Sensor C# [csharp]
WARN: Your project contains C# files which cannot be analyzed with the scanner you are using. To analyze C# or VB.NET, you must use the SonarScanner for .NET 5.x or higher, see https://redirect.sonarsource.com/doc/install-configure-scanner-msbuild.html
INFO: Sensor C# [csharp] (done) | time=1ms

I’m not sure why since I’m using the DevOps task in msbuild mode which works on another project (though that project is not related to service fabric).

What am I missing here?

5

Hello @Logan_Dam, welcome to our community. Apologies for the delay.

The analyzer is a Roslyn analyzer which gets executed during the build by csc.exe (the C# compiler).

This should be in the build step. Anyway, concurrent execution is now turned on by default so you can remove this.

If they don’t get built, the code won’t be analyzed.

The error is raised here.

If the project does not contain MAIN or TEST files … we should log a warning to the user, because no files will be analyzed.

If no code is built, then no files are analyzed. If no files are analyzed, the plugin which pushed the analysis data to SonarQube thinks that it hasn’t been invoked with the correct scanner (because no C# analysis happened).

I hope this helps.

6

Thanks for the response. I’ve actually worked around the issue by just using a dotnet build instead of using msbuild directly (via the VSBuild task).

It was really weird behaviour. When using VSBuild, whether the projects were set to build or not, the analyzer always picked things up as duplicates. Since switching to using dotnet build, I don’t have the issue anymore.

1 Like
8

Thanks for the reply!

I actually missed this part from your initial question:

Interesting. Do you happen to have a sample project where this issue is reproduced (VSBuild vs dotnet build)? We could see what’s different in the build process to understand and improve the user experience.