Is there any information as to when the dot net sonarscanner is updated to dotnet core 3.0?
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].
HI
Thanks for the info here.
i am also facing the same issue with core3.0, where i am having all commands in a docker file and when i am trying to execute the same i am ending with the same error.
I have seen some post where it says that scanner should support 3.0 from core3.0 release but i am still facing issue ( not preview core 3.0),can you please guide me on how to solve this issue ?
or please share us a working docker file for reference .
Thanks in advance.
Manoj
I am running with the same issue where my solution is build on Core 3.0 and when I take the docker image with core 3.0 and install the SonarScanner tool and when trying to execute BEGIN command the scanner see the issue
It was not possible to find any compatible framework version
The specified framework âMicrosoft.NETCore.Appâ, version â2.0.0â was not found.
- The following frameworks were found:
3.0.0 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
This is in need of Core SDK 2.1 for SonnarScanner and Core 3.0 for my solution.
All my commands are from Docker file and executed from the same, I see in your post that the core 3.0 supports the scanner but Iâm still facing issue is there somethig that Iâm missing.
can you please help me to resolve this issue.
Hi,
Which version of the scanner are you running currently ?
Thanks.
HI
I am using this version of scanner 4.7.1
Thanks,
Manoj.
Version 4.8.0 is out, bringing support of .NET Core 3 âonlyâ on host, but the Azure DevOps extension has not been updated yet with this version. You can however download the standalone release here
Mickaël
When will the Azure DevOps extension get updated with the scanner that supports .Net Core 3.x?
Any news on when the DevOps Extension will be updated?
Can the dotnet-sonarscanner be used for SAST (security testing) or just code quality for .NET core 3.0? Or is there a separately package for this?
Every scan includes issues related to bugs, code smells and vulnerabilities. Therefore every scan is, in effect, a SAST scan.