sonar-scanner-msbuild
sonar-scanner-msbuild copied to clipboard
SonarSource
dotnet-sonarscanner won't run in a dotnet/core/sdk container
Description
dotnet core sdk container cannot run the dotnet-sonarscanner I get the following error "Cannot find local application data directory."
I think this can be fixed by overriding the function and looking for DOTNET_RUNNING_IN_CONTAINER env variable. If it has that variable use Environment.GetEnvironmentVariable("LocalAppData") instead of Environment.SpecialFolder.ApplicationData
I tested this theory by running the following sample code locally and in the dotnet/core/sdk:3.1 container.
using System; namespace sonartest { class Program { static void Main(string[] args) { var lad = Environment.SpecialFolder.LocalApplicationData; Console.WriteLine("LocalApplicationData Enum Value: " + lad); var dnv = Environment.SpecialFolderOption.DoNotVerify; Console.WriteLine("DoNotVerify Enum Value: " + dnv); var pathResult = Environment.GetFolderPath(z, p); Console.WriteLine("Path: "+ pathResult); Console.WriteLine("ENV Varible is: " + Environment.GetEnvironmentVariable("LocalAppData")); } } }
Repro steps
I'm using a sonar-project.properties file.
using the following container image:
FROM mcr.microsoft.com/dotnet/sdk:3.1
Install the tool :
RUN setx PATH "%PATH%;C:\Users\ContainerUser.dotnet\tools"
RUN dotnet tool install --global dotnet-sonarscanner --version 5.1.0
RUN dotnet sonarscanner begin
I get the following error
"Cannot find local application data directory." from this line of code
https://github.com/SonarSource/sonar-scanner-msbuild/blob/master/src/SonarScanner.MSBuild.Common/MsBuildPathSettings.cs#L75
I suspect that it is because the container does not have this value set: https://github.com/SonarSource/sonar-scanner-msbuild/blob/0779f4d58eec352021ce36e32fe8df574c78bba8/src/SonarScanner.MSBuild.Common/MsBuildPathSettings.cs#L124
Expected behavior
Expect the scanner to execute the begin stage.
Actual behavior
Throws and exception with the following message "Cannot find local application data directory."
Known workarounds
None that i know of
Related information
- SonarScanner for MSBuild version: 5.10
- SonarQube server version: Version 7.9.5 (build 38598)
- Languages in your solution C# .net core 3.1
Here is another stackoverflow question bringing up the same issue with no workaround: https://stackoverflow.com/questions/64916082/sonar-scanner-cant-find-local-app-data-folder
Hi @kms254
Thanks for bringing this up. We'll have a look.
@mickael-caro-sonarsource Anything I can do to help, I made a local version/test that essentially checks to see if its running in the windows container and sets the value from Environment.GetEnvironmentVariable("LocalAppData") in the function environmentContainerGetFolderPath in the MSBuildPathSettings.cs file.
Hi @kms254
If you have something working, i would suggest to submit a PR if you wish, i'll have a look at it. Thanks !
@mickael-caro-sonarsource Has there been any progress made on this ticket? We've been attempting to migrate our CI system to build with Docker containers and have been seeing the same issues with the dotnet-sonarscanner (v5.2.1 & v5.2.2).
@mickael-caro-sonarsource Any updates? Still facing the same issue with dotnet sonarscanner v5.2.2
For what its worth, running the latest sonarScanner for MSBuild Jenkins Plugin also produces the exact same error
We're also running into this issue using a nanoserver image (mcr.microsoft.com/dotnet/sdk:5.0-nanoserver-2004) and dotnet-sonarscanner v5.3.1
A fix or solution would be appreciated as we're planning to move forward performing the sonar scan during our docker builds more often.
Same issue here. The base image being used is mcr.microsoft.com/dotnet/core/sdk:3.1.
It's a nanoserver problem: https://github.com/dotnet/runtime/issues/21430 Because the environment vars can be used to work around this issue, I believe the solution proposed the original post by @kms254 should be used. This is blocking me from using Sonar at the moment.
TL;DR Don’t use nanoserver. For DotNet 5, there’s a new servercore based image that will work correctly.
The reason that this is failing is because nanoserver system calls return empty strings for all system paths. The call is separate from the environment variables, which actually has the local application data path even in nanoserver. The solution of using the environment variable if an empty string is encountered from the system call could make Sonar Scanner for MSBuild work correctly, but I'm guessing that nobody is looking at this issue, so the best course of action is to upgrade to DotNet 5 and use a servercore based image instead of the nanoserver images, which are unfortunately the default.
TL;DR Don’t use
nanoserver. For DotNet 5, there’s a newservercorebased image that will work correctly.The reason that this is failing is because
nanoserversystem calls return empty strings for all system paths. The call is separate from the environment variables, which actually has the local application data path even innanoserver. The solution of using the environment variable if an empty string is encountered from the system call could make Sonar Scanner for MSBuild work correctly, but I'm guessing that nobody is looking at this issue, so the best course of action is to upgrade to DotNet 5 and use aservercorebased image instead of thenanoserverimages, which are unfortunately the default.
This seems like it worked for me, but i'm still not 100% functional.
Once moving the build container to mcr.microsoft.com/dotnet/sdk:5.0-windowsservercore-ltsc2019, SonarScanner started to work. Once I hit the end stage I noticed I had to install Java. Then After installing java I am hitting an issue with the arguments being malformed using dotnet tooling.... https://github.com/SonarSource/sonar-scanner-msbuild/issues/948
It just seems like every step of the way running this in a container(at least in windows) it is fighting me..
The downside of using the .net 5 container to build .net core 3.1 is we have a policy of using LTS and are waiting for .net 6.0 so I think this may confuse the developers that .net 5 is ok..
@kms254 sorry for the lack of reaction on this one.
Can you confirm that we can close this?
