MSBuild mode: How to scan c#, csproj and nuget.config files in same scan?

In short
I have written custom XPATH xml rules to detect problems with the nuget.config and csproj, i have confirmed the rules work when not using scannerMode MSBuild. However, trying combine MSBuild to detect c# problems with xml rules seems damn freaking hard…

The fact that i cant easily setup a scan of a folder structure containing c# and other non-c# files, but are instead forced into this idea that when your scanning a .net project you can only scan the content of the csproj-projects folders is annoying at best.

I have a folder structure like this

      nuget.config         <- Is scanned, but only added it for testing
      InternalApi.csproj   <- Not scanned
   nuget.config            <- Not scanned

We are using Azure DevOps pipelines

- task: SonarQubePrepare@5
  displayName: Sonarqube prepare
    SonarQube: $(sonarqube_service_connection)
    scannerMode: 'MSBuild'
    projectKey: $(sonarqube_projectKey)
    projectName: $(sonarqube_projectName)
    cliSources: '$(Build.SourcesDirectory)'
    extraProperties: |
- task: DotNetCoreCLI@2
  displayName: 'dotnet build'
    command: build
    projects: '$(path_to_solution)'
    arguments: --configuration $(BuildConfiguration) --no-restore
- task: SonarQubeAnalyze@5
  displayName: Sonarqube analyze

Stripped InternalApi.csproj file

<Project Sdk="Microsoft.NET.Sdk.Web">

I have tried to run two separate analyze jobs, but the last analyze overwrite the first. Which in effect deletes comments on the Azure DevOps PR.

I struggle with

  • Detect the csproj file within the project
  • Detect the nuget.config file outside the project structure
  • Run two separate scans and combine the result

Extra info

  • which versions are you using:
  • how is SonarQube deployed: Helm

Relevant logs from azure devops pipeline step

Starting: Sonarqube prepare
Task         : Prepare Analysis Configuration
Description  : Prepare SonarQube analysis configuration
Version      : 5.19.1
Author       : sonarsource
Help         : Version: 5.19.1. [More Information](
/usr/bin/dotnet /agent/_work/_tasks/SonarQubePrepare_15b84ca1-b62f-4a2a-a403-89b77a063157/5.19.1/dotnet-sonar-scanner-msbuild/SonarScanner.MSBuild.dll begin /k:SystemInfo
SonarScanner for MSBuild 5.15
Using the .NET Core version of the Scanner for MSBuild
Pre-processing started.
Preparing working directories...
13:27:43.079  Updating build integration targets...
13:27:43.842  Fetching analysis configuration settings...
13:27:44.203  Provisioning analyzer assemblies for cs...
13:27:44.204  Installing required Roslyn analyzers...
13:27:44.205  Processing plugin: csharp version
13:27:44.788  Processing plugin: vbnet version
13:27:44.84  Processing plugin: securitycsharpfrontend version
13:27:45.024  Provisioning analyzer assemblies for vbnet...
13:27:45.024  Installing required Roslyn analyzers...
13:27:45.024  Processing plugin: csharp version
13:27:45.025  Processing plugin: vbnet version
13:27:45.109  Downloading cache. Project key: SystemInfo, branch: master.
13:27:45.148  Incremental PR analysis: 0 files out of 150 are unchanged.
13:27:45.207  Pre-processing succeeded.
Finishing: Sonarqube prepare
Starting: Sonarqube analyze


Task : Run Code Analysis

Description : Run scanner and upload the results to the SonarQube server.

14:05:59.779 The exclude flag has been set so the project will not be analyzed. Project file: /agent/_work/12/s/Source/Sec_SystemInfo.Migrations/Sec_SystemInfo.Migrations.csproj
14:05:59.786 Using longest common projects path as a base directory: '/agent/_work/12/s/Source'.
14:05:59.81 File was referenced by the following projects: '/agent/_work/12/s/Source/InternalMessaging.Batch.Tests/InternalMessaging.Batch.Tests.csproj', '/agent/_work/12/s/Source/InternalApi.Tests/InternalApi.Tests.csproj', '/agent/_work/12/s/Source/Logic.Tests/Logic.Tests.csproj'.
14:05:59.821 Dumping content of



My first question is whether XML is analyzed at all when you use SonarScanner for .NET, or whether it is analyzed but your rules don’t run?

And what is your project type? “For newer SDK-style projects” everything is supposed to be picked up automatically. Otherwise, you may need to adjust your project files.

Also, the current scanner version is 6.2. I don’t think this will impact your problem, but could you upgrade and try again just to eliminate that variable?



As a followup, it’s been pointed out to me that the latest scanner version isn’t yet available through the ADO extension, so nevermind that part.


1 Like

Xml was analyzed, and my rules was hitting where expected (which in end resultet in comments to the azure devops pull request)

And what is your project type? “For newer SDK-style projects” everything is supposed to be picked up automatically. Otherwise, you may need to adjust your project files.

I read clues that one had to include the files in the csproj project one by one file. This is not an option. We are an organization with 150+ csproj files/projects, we cant maintain them based on what an external tool should scan. In addition; including the csproj file itself in the csproj file config seems silly.


No, wildcards work. That’s still a lot for 150+ csproj files, but better than one-by-one. :sweat_smile:

Yeah… I get that. And honestly, I don’t think we ever foresaw wanting to run rules on the project files.

Would you mind sharing what you want to check in them?


I can add images of the rules, easier/quicker

1 Like


Thanks for sharing.

In fact, one of our devs routinely gives a talk about avoiding Nuget dependency confusion attacks, so I’m a little surprised we haven’t beaten you to the punch on this. I’ll make sure the devs see this.


1 Like

Hi @ganncamp and @Andre_Hansen

We got a related request earlier from the community

We created an issue to track the rule request here:

We also did a short investigation on how to implement such a rule in the .Net analyzer back then. We only checked how such issues are reported in the IDE but not on the SonarQube/SonarCloud servers. We should consider adding *csproj, *.config, *.sln, and similar files by default. Without such files, the code view on the server is missing important artifacts anyway.

The two rules shown by @Andre_Hansen are interesting. Unfortunately, they are very noisy with a high false positive rate. If we add such rules, they will have to be disabled by default, and users will need to opt in explicitly.