Is there any information as to when the dot net sonarscanner is updated to dotnet core 3.0?
Dotnet core 3.0 dotnet-sonarscanner
Hi Ben. Welcome to the community.
We don’t have currently have a plan to release a version of the scanner built against .NET Core 3.0.
For the time being it is still necessary to have version 2.x of the .NET Core Runtime installed on the machine for the NET Core version of the scanner to work (and at least v2.1 if you are using the global tool).
Just to be clear, the scanner is capable of analysing projects that target NET Core v3.0, and has been since v4.7.
Is needing to have two versions of .NET Core installed a major problem for you?
For us it’s not a major problem, but it is complicating all our build definitions. To work around Sonar we have to do something like this:
-
task: UseDotNet@2
displayName: ‘Use .NET Core sdk 2.2’ -
task: SonarSource
-
task: UseDotNet@2
displayName: ‘Use .NET Core sdk 3’ -
task: DotNetCoreCLI@2
displayName: ‘Restore, Build & Test with coverage’ -
task: UseDotNet@2
displayName: ‘Use .NET Core sdk 2.2’ -
task: SonarSource
Not sure if it’s easily done, but it should be possible to multitarget the scanner:
For libraries like this:
Exe:
Do you actually need to install each framework multiple times? I’d have expected that you could install v2.2 and v.3 as the first two steps of the build pipeline, and then everything else should work correctly.
I’m guessing you are using Azure Pipelines. By task: SonarSource, do you mean the Azure DevOps extension for SonarQube/Cloud, or are you running the Scanner for MSBuild directly?
If you’re running the scanner directly, you could try using the new major version roll-forward feature that was introduced in .NET Core 3.0 e.g.
dotnet --roll-forward Major d:\Tools\scanner\latest\dotnet\sonarscanner.msbuild.dll
Are you using Microsoft-hosted build agents or self-hosted build agents? The Microsoft-hosted build agents all have multiple versions of .NET Core installed by default, although it looks like only the agents in the windows-2019 pool have .NET Core 3.0 currently.
Good questions, thank you. We are running self hosted in Docker with microsoft/vsts-agent:ubuntu-16.04-standard image, and you’re right we are using Azure pipelines with Sonar Cloud extension.
I was under the impression that Sdk 2.2 was already in the docker image, because we never installed it with the task. Adding .Net Core 3 install task caused Sonar to error because 2.0 could not be found. That’s the reason I was switching between .Net Sdk 2.2 and 3. I was reasoning, the task is called UseDotNet for a reason.
But it’s indeed enough to install both Sdks at the beginning. Still not sure why I need to install 2.2, because it was using the default Sdk from the image before.
Long story short, this works:
* task: UseDotNet@2
displayName: ‘Use .NET Core sdk 2.2’
* task: UseDotNet@2
displayName: ‘Use .NET Core sdk 3’
* task: Prepare analysis on SonarCloud
* task: DotNetCoreCLI@2
displayName: ‘Restore, Build & Test with coverage’
* task: SonarCloud Run Code Analysis
Thanks for helping. This is a really small change we need to make to our pipelines and it’s arguably better just to define the Sdks we are using anyway.
Great. Yes, the name of the task is unhelpful.
I ran dotnet --list-runtimes in a build job against the Ubuntu image and it has forty (!) versions of the .NET Core app runtime installed, including four 2.2.x versions. I don’t understand why installing 2.2 is necessary, or why adding .NET Code 3 would break the SonarCloud extension. Still, the main thing is that it is working.
FYI I’ve created this ticket in the backlog to investigate whether we would ship a version that would work against both .NET Core v2 and v3.
Hi
Thanks @duncanp for the info you’ve provided
This is an issue for us, we build dotnet core (aspnet) cloud services, and our build environment is containerized using docker. Our build agents are blank linux machines with docker and all they run is the linux Azure DevOps build agent. The dotnet compiler runs inside a copy of microsoft’s dotnet/core/sdk:3.0 image. This is very handy as it’s trivial to migrate to new versions and minor security patches come down with zero work and there’s no mess caused by having loads of different tools all sitting together in the same environment. Highly recommended.
Anyway, Microsoft’s SDK image obviously only has .NET core 3 and nothing else.
I could move from Microsoft’s SDK container image to a custom built one and install .NET 2.2 and other stuff in there, but I’m really not keen to do that as then we would be responsible for keeping on top of all the minor .NET updates and all that stuff again, and the whole system becomes a lot more complex.
I tried the roll forward feature (setting the DOTNET_ROLL_FORWARD environment variable to Major). The initial “prepare analysis” step now passes, and I can see in the build log output that the Sonar roslyn analyzer is indeed installed and working correctly, the final “run code analysis” step fails with this error:
2019-10-02T10:35:10.9303818Z Task : Run Code Analysis
2019-10-02T10:35:10.9303875Z Description : Run scanner and upload the results to the SonarQube server.
2019-10-02T10:35:10.9303992Z Version : 4.8.0
2019-10-02T10:35:10.9304046Z Author : sonarsource
2019-10-02T10:35:10.9304178Z Help : This task is not needed for Maven and Gradle projects since the scanner should be run as part of the build.
[More Information](http://redirect.sonarsource.com/doc/install-configure-scanner-tfs-ts.html)
2019-10-02T10:35:10.9304282Z ==============================================================================
2019-10-02T10:35:11.5676227Z [command]/usr/bin/dotnet /__w/_tasks/SonarQubePrepare_15b84ca1-b62f-4a2a-a403-89b77a063157/4.8.0/dotnet-sonar-scanner-msbuild/SonarScanner.MSBuild.dll end
2019-10-02T10:35:11.6242284Z SonarScanner for MSBuild 4.7.1
2019-10-02T10:35:11.6246175Z Using the .NET Core version of the Scanner for MSBuild
2019-10-02T10:35:11.7010302Z Post-processing started.
2019-10-02T10:35:11.9314285Z Calling the SonarQube Scanner...
2019-10-02T10:35:11.9463479Z Could not find 'java' executable in JAVA_HOME or PATH.
2019-10-02T10:35:11.9525726Z ##[error]The SonarQube Scanner did not complete successfully
2019-10-02T10:35:11.9535463Z The SonarQube Scanner did not complete successfully
2019-10-02T10:35:11.9536234Z ##[error]10:35:11.948 Post-processing failed. Exit code: 1
2019-10-02T10:35:11.9536830Z 10:35:11.948 Post-processing failed. Exit code: 1
2019-10-02T10:35:11.9615286Z ##[error]The process '/usr/bin/dotnet' failed with exit code 1
2019-10-02T10:35:12.0073590Z ##[section]Finishing: Run Code Analysis
Could not find java? Java?? JAVA?!??@?!
Anyway, it looks like the dotnet roll forward part is working, so that information may be of use to others. I’m not keen to junk up our dotnet core build container with java though. Are there any options to have it work without java?
Thanks
Orion
Hi @Orion_Edwards,
Yes, the Scanner for MSBuild it actually a wrapper over the “real” scanner which is programmed and ran with Java, so you still need to run your analysis from a place where java is installed.
Mickaël
I’m having a similar issue. I build a mobile app using AppCenter and I have a pre-build script to install and run sonarscanner against the project. This used to work until we upgraded our project to use .NET Core 3.0. AppCenter automatically downloads the version of .NET required to build the project (which is 3.0) and sonar fails because it’s looking for an older version of the SDK. If I could download a version of sonarscanner built against 3.0 I believe this problem would go away.
From my build server…
You can invoke the tool using the following command: dotnet-sonarscanner
Tool ‘dotnet-sonarscanner’ (version ‘4.7.1’) was successfully installed.
Starting Sonar Scan…
A fatal error occurred. The required library libhostfxr.dylib could not be found.
If this is a self-contained application, that library should exist in [/Users/runner/.dotnet/tools/.store/dotnet-sonarscanner/4.7.1/dotnet-sonarscanner/4.7.1/tools/netcoreapp2.1/any/].
If this is a framework-dependent application, install the runtime in the global location [/usr/local/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].