Hi Antonio,
thanks for the effort! I can also confirm that the work around works.
Wish you the best
Peter
2 Likes
Thanks @antonio.aversa! We will check if the workaround works for us.
Hi,
We have figured out why the Scanner keeps using ~/.local/share.
The good news is that:
- the problem will fix itself with the final release of .NET 8
- and we have a better workaround than copying target files to
~/Library/Application Support, which will keep working after the final .NET 8 release in November.
So you won’t need to update the Scanner, to have the problem fixed permanently.
The issue
The scanner declares net5.0 as its target framework, with RollForward set to LatestMajor, to have it run with the most recent version of the .NET SDK installed.
However, the default behavior of the rolling mechanism is to not take into account preview versions of the .NET SDK.
Therefore, when a version of .NET < 8 Preview is installed (such as .NET 7) alongside .NET 8 preview, the scanner is run against that version, instead of .NET 8 Preview.
The behavior can be changed by using the DOTNET_ROLL_FORWARD_TO_PRERELEASE environment variable.
After the release of .NET 8, the rollback mechanism will work normally, and the environment variable won’t be needed anymore. If left there, however, it should not do any harm, and it will help test preview releases of future versions of .NET.
The workaround until .NET 8 is released
The workaround is to set to 1 the DOTNET_ROLL_FORWARD_TO_PRERELEASE environment variable, before running the scanner begin:
export DOTNET_ROLL_FORWARD_TO_PRERELEASE=1
To verify that the workaround is working correctly you can:
- if you have applied the previous workaround: remove the target files and folders created by hand in
~/Library/Application Support/Microsoft/MSBuild/, before running the scanner begin - use
printenvto make sure the environment variable has been set correctly in your context - run the
sonarscanner beginwith an additional parameter/d:sonar.verbose=trueand check whether the scanner is copying the target files into~/Library/Application Supportinstead of/.local/share. - check that target files actually exist in
~/Library/Application Support/Microsoft/MSBuild/*/Microsoft.Common.targets/ImportBefore
Let me know if the new workaround works for you.
Thanks,
Antonio
4 Likes
unfortunately the workaround does not work for us. We followed your steps and get this exception in the end step:
26-Oct-2023 14:08:42 SonarScanner for MSBuild 5.13.1
26-Oct-2023 14:08:42 Using the .NET Core version of the Scanner for MSBuild
26-Oct-2023 14:08:42 Post-processing started.
26-Oct-2023 14:08:42 14:08:42.473 14:08:42.473 WARNING: File '/Users/yygte69/Development/BambooAgents/APPME-Agent-P-3/xml-data/build-dir/MIEL-MMA432-AUTHENTICATIONTESTS/packages/microsoft.net.test.sdk/17.6.2/build/netcoreapp3.1/Microsoft.NET.Test.Sdk.Program.cs' is not located under the base directory '/Users/yygte69/Development/BambooAgents/APPME-Agent-P-3/xml-data/build-dir/MIEL-MMA432-AUTHENTICATIONTESTS/src' and will not be analyzed.
26-Oct-2023 14:08:42 14:08:42.473 14:08:42.473 WARNING: File '/Users/yygte69/Development/BambooAgents/APPME-Agent-P-3/xml-data/build-dir/MIEL-MMA432-AUTHENTICATIONTESTS/packages/nunit3testadapter/4.4.2/build/netcoreapp3.1/NUnit3.TestAdapter.pdb' is not located under the base directory '/Users/yygte69/Development/BambooAgents/APPME-Agent-P-3/xml-data/build-dir/MIEL-MMA432-AUTHENTICATIONTESTS/src' and will not be analyzed.
26-Oct-2023 14:08:42 Calling the SonarScanner CLI...
26-Oct-2023 14:08:42 Unhandled exception. System.ComponentModel.Win32Exception (13): An error occurred trying to start process '/Users/Shared/Applications/sonar-scanner-msbuild-net5.0/sonar-scanner-4.8.1.3023/bin/sonar-scanner' with working directory '/Users/yygte69/Development/BambooAgents/APPME-Agent-P-3/xml-data/build-dir/MIEL-MMA432-AUTHENTICATIONTESTS'. Permission denied
26-Oct-2023 14:08:42 at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
26-Oct-2023 14:08:42 at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.Common.ProcessRunner.Execute(ProcessRunnerArguments runnerArgs)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.Shim.SonarScannerWrapper.ExecuteJavaRunner(AnalysisConfig config, IEnumerable`1 userCmdLineArguments, ILogger logger, String exeFileName, String propertiesFileName, IProcessRunner runner)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.Shim.SonarScannerWrapper.InternalExecute(AnalysisConfig config, IEnumerable`1 userCmdLineArguments, ILogger logger, String fullPropertiesFilePath)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.Shim.SonarScannerWrapper.Execute(AnalysisConfig config, IEnumerable`1 userCmdLineArguments, String propertiesFilePath)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.PostProcessor.PostProcessor.InvokeSonarScanner(IAnalysisPropertyProvider cmdLineArgs, AnalysisConfig config, String propertiesFilePath)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.PostProcessor.PostProcessor.Execute(String[] args, AnalysisConfig config, IBuildSettings settings)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.BootstrapperClass.PostProcess()
26-Oct-2023 14:08:42 INFO: exitcode: 134
26-Oct-2023 14:08:42
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.BootstrapperClass.Execute()
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.Program.Execute(String[] args, ILogger logger)
26-Oct-2023 14:08:42
26-Oct-2023 14:08:42 ------------------------------------------------------------------------------
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.Program.Execute(String[] args)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.Program.Main(String[] args)
26-Oct-2023 14:08:42 at SonarScanner.MSBuild.Program.<Main>(String[] args)
The Win32Exception in the end step seems related to access rights, which may be potentially unrelated to the previous issue.
Could you provide new logs (via private message), running begin and end step commands with /d:sonar.verbose=true and the .NET build command with /v:d?
The first thing to check is whether the analysis is now actually happening: after setting export DOTNET_ROLL_FORWARD_TO_PRERELEASE=1, if you run the begin step with the additional parameter /d:sonar.verbose=true, do you see from the logs that ~/Library/Application Support/Microsoft/MSBuild/ is being used, instead of ~/.local/share/Microsoft/MSBuild/?
An alternative way is to check the .sonarsource/out folder, under the project folder: after the .NET build command it should be populated with subfolders (e.g. 0, ucfg_cs2, etc.).
Thanks,
Antonio
Hi,
I checked both and the correct folder is used. I also can find the subfolders in .sonarsource/out.
I also executed it as sudo but still the same
EDIT: the infos above only apply for the begin command. I seems like the end step still wants to use the incorrect folder. (the env var is set)
Good news, the workaround works now for us too. We were able to fix the permission error with this:
We also updated the sonar scanner to 5.14.0.
@all Thanks for your efforts!
4 Likes
Hi @Christopher_Stephan,
That’s excellent news!
Thank you for providing logs and details about the issue.
Best regards,
Antonio
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.