C# Sonar Scanner with Source Generators

SonarQube Cloud
, , ,
1

Hello,

We have been having a problem with sonar scanner version 8.20 (we also tried with 5.22 and 5.4). We have some property that are generated through Source generators. The build is working fine. However, running sonarscanner fails with these types of errors :

  • Error CS0117: ‘FirstStoreEntity’ does not contain a definition for ‘PropString1’
  • Error CS0117: ‘FirstStoreEntity’ does not contain a definition for ‘PropBool1’
  • Error CS0117: ‘FirstStoreEntity’ does not contain a definition for ‘PropInt1’

This is very similar to the first post of this thread C# analysis failing hard when source generators are used · Issue #4100 · SonarSource/sonar-dotnet · GitHub

Is sonar scanner supporting c# Source Generators?

Thanks!

2

Hello and welcome to the community!

Is it related to Razor files in .NET 6? We have #1125 to track this.

Otherwise, please give us the following version information:

  • what is the version of SonarQube that you are using?
  • what is the version of the Scanner for .NET (MSBuild) that you are using?
  • what version of MSBuild are you using?

And we’ll need the logs:

  • please give us the verbose output of the scanner commands (please run SonarScanner.MSBuild.exe begin /k:“MyProject” /d:sonar.verbose=true as the begin step, and please attach the output of the BEGIN and END steps)
  • please give the output of running MSBuild in verbose mode (/v:d)

Also, please tell us:

  • what are the commands you are running to do the analysis?
  • are you running all commands from the same folder?
3

Hi @Andrei_Epure,

It’s not related to Razor files.

We are using .NET 6.

Version of SonarQube → Community Edition Version 7.9.2 (build 30863)
Version of SonarScanner for .NET → 5.4.0
Version of MSBuild:
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.187.0
Author : Microsoft Corporation
Help : .NET Core CLI task - Azure Pipelines | Microsoft Docs

Commands to do the analysis:

  • task: DotNetCoreCLI@2
    displayName: ‘dotnet install sonarscanner’
    inputs:
    command: custom
    custom: tool
    arguments: ‘install --global dotnet-sonarscanner --ignore-failed-sources --version 5.4.0’

  • task: DotNetCoreCLI@2
    displayName: ‘dotnet sonarscanner begin’
    inputs:
    command: custom
    custom: sonarscanner
    arguments: ‘begin /k:“contextengine-runnerapi” /d:sonar.host.url="[Url]" /d:sonar.login="[Login]" /v:"$(Build.SourceBranchName)" /d:sonar.exclusions=**/*k8s’

  • task: DotNetCoreCLI@2
    displayName: ‘dotnet restore’
    inputs:
    command: restore
    projects: ‘**/*.csproj’

  • task: DotNetCoreCLI@2
    displayName: ‘dotnet build’
    inputs:
    projects: ‘**/[SolutionName].sln’
    arguments: ‘-c Release’

  • task: DotNetCoreCLI@2
    displayName: ‘dotnet sonarscanner end’
    inputs:
    command: custom
    custom: sonarscanner
    arguments: ‘end /d:sonar.login=[Login]’

All commands are running from the same folder

4

It fails in the dotnet build steps.

If we comment out the sonarscanner begin and end, the dotnet build step works without errors

A sample project like GitHub - costin-zaharia-sonarsource/source-generators-poc: Proof of concept for analyzing source generators could be used to reproduce the problem!

6

For the record, I’ve tried reproducing the problem with @costin.zaharia 's POC (after changing the TFM to net6 in both projects - see PR) and could not. The analysis is successful (see on SC).

I’ve used sonar-scanner-msbuild-5.3.2.38712-netcoreapp2.0 and dotnet 6.0.100.

7

I don’t think it can work if you change the framework to .net 6 on the generator project. It’s supposed to be .net standard 2.0 (See Creating an incremental generator: Creating a source generator - Part 1). It’s however ok to switch to .net 6 for the console application.

Are you able to reproduce the problem if you switch back the generator project to .net standard 2.0 and keep the console app to .net 6?

8

We updated sonarqube to 8.9.3 (build 48735) and it seemed to have fixed our problem!

Thanks for you help!

10

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