Configuring the .NET scanner tool using SonarQube.Analysis.xml is very poorly documented. As far as my experience goes, it’s only mentioned in a couple of places, including this document. I would love to see some more comprehensive instructions on how to override the .NET scanner config using this method, especially in a pipeline.
Related to this, I’m not seeing any way to using this method of configuring the scanner in Azure DevOps pipelines using tasks using the “dotnet” scanner mode from either extension (SonarQube Cloud or SonarQube Server). You do have the ability to specify the config file for the “cli” scanner mode, but it’s not clear if you can use SonarQube.Analysis.xml in this mode. Realistically, though, using the .NET scanner for a .NET project is what we should be doing, since it hooks into the build process, so using the CLI scanner feels less-desirable.
While it’s nice to be able to pass in configuration parameters in the pipeline task itself, we would prefer to keep them all in a file and pass that into the scanner. Is it possible that there’s a way to do this already and I just haven’t found how? Please let me know if there’s anything I can clarify or can provide any more information.
You must use the SonarScanner for .NET to analyze .NET code. The ‘cli’ option is there because not every project stored in Azure DevOps is .NET.
If you specify the ‘cli’ mode, then you’ll use the SonarScanner CLI which looks for sonar-project.properties and does not read XMl files.
You won’t find that documentation because that’s not what the file is for. Per the docs this file is a central scanner configuration intended for configuring values that will be global to all analyses, such as (from the docs):
Sorry, but that’s just not how SonarScanner for .NET works.
I understand that SonarQube.Analysis.xml overrides the global scanner configuration, however, we’re using this method to better handle the exclusion of certain directories (or whatever else we need to configure). When running the scan (manually in our pipelines using the .NET tool), we’ve just been passing the -s option in to override the global config. According to this section in the advanced setup guide, it seems like using the SonarQube.Analysis.xml override is the correct and expected method of configuring scans. If that’s not the case, the documentation should be updated, so as to not give that impression.
The way we need to do things currently with the ADO pipeline tasks is to specify the scanner parameters in the extraProperties field in each pipeline (we can easily end up with 3 or more pipeline per repo), or override the global configuration and have all the same configuration in a single file. I recognize that it’s fine to repeat yourself in code at times, but in this case, it does feel a little unnecessary and being able to pass in the path to the SonarQube.Analysis.xml or some other configuration file that isn’t a global override would be really helpful.
Uhm… No. It is an option, listed on that page for completeness.
In fact, it has been listed on that page incorrectly, IMO (which I will raise internally). It is intended to configure the scanner, rather than configuring an individual project or analysis. It is akin to the sonar-scanner.properties file, that has somehow fallen out of the SonarQube Cloud documentation (but which still exists in the SonarQube Server docs) that configures global properties that apply to all analyses run on the build agent for the SonarScanner CLI.
Ok. Thanks for confirming that it’s not the preferred way of doing things and thanks for raising the issue. Is there anything in the works for a per-project configuration file for the .NET scanner?
Just to confirm, in the meantime, we should stick with putting our settings in the .NET project files and/or the pipeline task’s extraProperties, right?
Hi, @ammonroberts
Indeed, you are not the first one to mention that need. While we do not have plans for this feature at the moment, I have recorded this in our tool for prioritization in the future!
Thank you for raising your hand on this topic, it’s the best way for us to figure out what is really important to you all!
