After updating the package dotnet-sonarscanner from 6.0.0 to 9.0.2 I’m facing the following error message
> C:\build\_work\_tool/dotnet\dotnet.exe C:\Users\***\.nuget\packages\dotnet-sonarscanner\9.0.2\tools\netcoreapp3.1\any\SonarScanner.MSBuild.dll begin /k:*** /d:sonar.token=[REDACTED] /d:sonar.host.url=*** /d:sonar.qualitygate.wait=true
Cannot copy a different version of the SonarScanner for MSBuild assemblies because they are used by a running MSBuild/.Net Core process. To resolve this problem try one of the following:
- Analyze this project using the same version of SonarScanner for MSBuild
- Build your project with the '/nr:false' switch
The problem looks a bit similar to my discussion regarding error message CS0006.
I think the distribution and caching into the several locations (%userprofile%\.sonar, %temp%\.sonarqube, project’s build directory like c:\build\_work\979) has some consistency issues.
It happened on a build agent with state.
I do not have any smaller example with reproduction steps.
I’m asking here for some information that helps me to understand what happens.
First, I just wrote down what happened. Similar to the other linked issue I’m a bit frustrated due to invisible dependencies. When running an analysis locally successful, I expect that the server build is working too. But, the hidden dependencies and caching makes the build more complex than expected.
Please, help me to understand the caching happens here rhat explains the described behavior.
I would need verbose debug logs to better understand the setup. As well as what commands you are running on your CI.
One important piece of the puzzle that changed between version 6 and version 9 is how we scan for files on disk, irrespective of the contents of the csproj (announcement).
To do this, we changed the way we compute the project base directory (docs for parameters - sonar.projectBaseDir). We show this in an info message :
Starting with Scanner for .NET v8 the way the sonar.projectBaseDir property is automatically detected has changed and this has an impact on the files that are analyzed and other properties that are resolved relative to it like sonar.exclusions and sonar.test.exclusions. If you would like to customize the behavior, please set the sonar.projectBaseDir property to point to a directory that contains all the source code you want to analyze. The path may be relative (to the directory from which the analysis was started) or absolute. ”
While I don’t know exactly the cause of your issue, this might be a reason of failures. Although I’m not sure that it would give the error message you see, TBH.
Also, I see we have an issue to improve the error message, and a page that should help you debug. The error message is related to in-memory processes that are kept alive by MSBuild for performance reasons.
Did you try to run the build with /nr:false?
Do you have on that machine pipelines that use different versions of the scanner?
In addition to what I mentioned previously about v6 to v9 changes, you asked about the caching behavior in the Scanner for .NET. “Incremental PR analysis” has been around for a while, since version 5.13, and it helps analyze only the diff inside a pull request.
To test functionally if incremental PR analysis is affecting your case (I doubt, as what you say likely manifests because of two different scanner versions running on the same machine), you can disable caching with sonar.analysisCache.enabled=false.
If you’re curious about this functionality, you can read this class.
No, because the problem appears with the server build I had to work-around the problem. I did not remember what I did. It was last year and x-mas-holiday happened…
So far, I did have time to restart detailed analysis. My post was intended to get information I can use to understand what happens.
For me, it is unexpected how many implicit activities get invoked in the background. Implicit caching in many different folders. I would prefer explicit caching, etc. to have full control on all activities.