Problem scanning .NET 8 targeted projects on MacOS

SonarQube Server / Community Build
, ,
26

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 printenv to make sure the environment variable has been set correctly in your context
  • run the sonarscanner begin with an additional parameter /d:sonar.verbose=true and check whether the scanner is copying the target files into ~/Library/Application Support instead 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