we are currently using the SonarQube extension for Azure DevOps version 5 on Azure agents in Windows and looking to upgrade our pipeline to use version 6. Unfortunately SonarQubePrepare@6 step downloads always the classic (.NET Framework) Sonar scanner while we use .NET6 / .NET8 which leads to errors.
I have seen in the code that the scanner download is tied to the platform on the machine (in our case Windows). Is it possible to add a property to the configuration that lets us choose which type of scanner (classic or .NET) we want to download in the prepare step (similar to msBuildVersion that lets you select the version of the scanner)?
I understand that we can solve the issue by switching to Linux based build agents however there are some obstacles so the option for selecting the scanner type would be highly appreciated.
Sure. I’ve just realized that not the SonarQubeAnalyze task is failing but the DotNetCoreCLI@2 task that we use for building and testing for SonarQube. The step - as is - works with SonarQubePrepare@5 but not with SonarQubePrepare@6.
Starting: Build and test for SonarQube
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.240.0
Author : Microsoft Corporation
Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
[...]
C:\hostedtoolcache\windows\dotnet\sdk\8.0.301\Current\SolutionFile\ImportAfter\Microsoft.NET.Sdk.Solution.targets(36,5): warning NETSDK1194: The "--output" option isn't supported when building a solution. Specifying a solution-level output path results in all projects copying outputs to the same directory, which can lead to inconsistent builds. [<solutionPath>]
C:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: The "IsTestFileByName" task failed unexpectedly. [<csProjectPath>]
C:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: System.IO.FileNotFoundException: C:\a\_temp\690f6df9-910e-4e85-bfc8-1c12c06f41ff\SonarQube.Analysis.xml [<csProjectPath>]
C:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: at SonarScanner.MSBuild.Common.Serializer.LoadModel[T](String fileName) [<csProjectPath>]
C:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: at SonarScanner.MSBuild.Common.AnalysisProperties.Load(String fileName) [<csProjectPath>]
C:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: at SonarScanner.MSBuild.Common.ConfigSettingsExtensions.GetAnalysisSettings(AnalysisConfig config, Boolean includeServerSettings, ILogger logger) [<csProjectPath>]
C:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: at SonarScanner.MSBuild.Tasks.IsTestFileByName.Execute() [<csProjectPath>]
C:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [<csProjectPath>]
C:\a\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [<csProjectPath>]
##[error]Error: The process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe' failed with exit code 1
##[warning].NET 5 has some compatibility issues with older Nuget versions(<=5.7), so if you are using an older Nuget version(and not dotnet cli) to restore, then the dotnet cli commands (e.g. dotnet build) which rely on such restored packages might fail. To mitigate such error, you can either: (1) - Use dotnet cli to restore, (2) - Use Nuget version 5.8 to restore, (3) - Use global.json using an older sdk version(<=3) to build
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://docs.microsoft.com/en-us/dotnet/core/tools/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
##[error]Dotnet command failed with non-zero exit code on the following projects : [ '<solutionPath>' ]
Looks like we have some auto-detection that should decide this:
And I suppose on Windows it says to always use the classic .NET Framework scanner, and otherwise use the dotnet scanner.
I’m not sure at the moment if the issue is that the classic scanner should work in this situation, or that we should find a better way to detect that we should be using the dotnet scanner. I’m tracking this down.
Could you provide your full Azure Devops Pipeline YML? You provided the output for DotNetCoreCLI@2, but I’m curious to see what it looks like in full, particularly SonarQubePrepare@6.
As mentioned in the thread that was split from this one, I found our issue. It appears we have a task that removed the working directory in order to have a clean Code coverage result. Since the scanner is downloaded in the Sonar task since version 6 it was removed with the working directory and thus was not found later on. We will adapt the pipeline accordingly.
I ran in yet another problem where our OWASP dependency check tried to upload files from the scanner for some reason but was able to resolve it by setting the report directory to a sub directory.