Often we are facing the problem, that a server build fails with the following message: CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\2\SonarAnalyzer.Security.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
The build agent is running on Windows, so this issue does not apply here.
We have some (older) build definitions using SonarAnalyzer for .NET Framework (version 6.1.0) which is manually deployed to the server. Other (newer) build definitions are using the version for net6 through the nuget package dotnet-sonarscanner version 6.0.0.
(I call the latter one “new” even the referenced package version is lower. I could not yet test whether the package version is related to the issue.)
It seams when running both build definitions on the same server, they raised conflicts each other.
I’m seriously wondering why the mentioned build of a project in the “new” environment with searching for SonarAnalyzer assemblies in users temp folder with a subfolder .sonarqube.
I guess it is released to other sonar folders on the server. I found
C:\Users\***\AppData\Local\Temp\.sonarqube
c:\Users\s_TFSBuilder\.sonar\
c:\build\_work\979\.sonarqube\ (the builds are running in context of Azure DevOps Server with self hosted agents)
Please help in understanding which folders are created, maintained, used by SonarAnalyzer in the current versions.
We are running many different builds on the build agents. To fully test I would need to update all projects.
We have internal approval work-flows for new (nuget) packages. I do not like to ask for new package versions just for testing.
Unfortunately I’m currently not able to reproduce the problem locally. This makes testing very complicated.
This is why I first ask for explanations of the intended behavior for the several .sonar* folders and whether they have changed since version 6.0.
How can a build process within c:\build\_work\979\ fail with a reference to C:\Users\***\AppData\Local\Temp\.sonarqube?
I’m not asking you to do it “just for testing”. I’m asking you to upgrade because a) you should keep up with the latest versions (we don’t put them out because we’re bored ) and b) I can’t answer these questions myself, and I can’t refer them to people who will have to go spelunking in old code to dig up the answers.
At least with dotnet-sonarscanner version 8.0.3 I could reproduce the error message above.
I could not update other analyzers which may create (savely) the other .sonar folders.
Why dotnet-sonarscanner 8.0.3 is accessing C:\Users\***\AppData\Local\Temp\.sonarqube while compilation?
The nuke project is compiled while executing the build. This compilation fails, see below.
The scanner is referenced as PackageDownload in the nuke project, see below.
BuildLog:
==============================================================================
Task : Command line
Description : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
Version : 2.212.0
Author : Microsoft Corporation
Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
==============================================================================
##[debug]VstsTaskSdk 0.9.0 commit 6c48b16164b9a1c9548776ad2062dad5cd543352
##[debug]Entering C:\build\_work\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.212.0\cmdline.ps1.
##[debug]Loading resource strings from: C:\build\_work\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.212.0\task.json
##[debug]Loaded 6 strings.
##[debug]SYSTEM_CULTURE: 'en-US'
##[debug]Loading resource strings from: C:\build\_work\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.212.0\Strings\resources.resjson\en-US\resources.resjson
##[debug]Loaded 6 strings.
##[debug]INPUT_FAILONSTDERR: 'false'
##[debug] Converted to bool: False
##[debug]INPUT_SCRIPT: './build.cmd Preparation BuildAndPack TestAndReport Sonar'
##[debug]INPUT_WORKINGDIRECTORY: 'c:\build\_work\1400\s'
##[debug]Asserting container path exists: 'c:\build\_work\1400\s'
Generating script.
Script contents: shell
./build.cmd Preparation BuildAndPack TestAndReport Sonar
##[debug]AGENT_VERSION: '3.225.2'
##[debug]AGENT_TEMPDIRECTORY: 'c:\build\_work\_temp'
##[debug]Asserting container path exists: 'c:\build\_work\_temp'
##[debug]Asserting leaf path exists: 'C:\Windows\system32\cmd.exe'
========================== Starting Command Output ===========================
##[debug]Entering Invoke-VstsTool.
##[debug] Arguments: '/D /E:ON /V:OFF /S /C "CALL "c:\build\_work\_temp\6d14adb5-ddba-4250-9de2-5bc748eef6e9.cmd""'
##[debug] FileName: 'C:\Windows\system32\cmd.exe'
##[debug] WorkingDirectory: 'c:\build\_work\1400\s'
"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "c:\build\_work\_temp\6d14adb5-ddba-4250-9de2-5bc748eef6e9.cmd""
PowerShell Desktop version 5.1.17763.6292
Microsoft (R) .NET SDK version 8.0.401
C:\build\_work\1400\s\build\nuke\nuke.csproj : warning NU1507: There are 8 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping (https://aka.ms/nuget-package-source-mapping) or specify a single package source. The following sources are defined: ***
C:\build\_work\1400\s\build\nuke\nuke.csproj : warning NU1507: There are 8 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping (https://aka.ms/nuget-package-source-mapping) or specify a single package source. The following sources are defined: ***
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\2\SonarAnalyzer.Security.dll' could not be found [C:\build\_work\1400\s\build\***.csproj]
##[debug]Exit code: 1
##[debug]Leaving Invoke-VstsTool.
##[error]Cmd.exe exited with code '1'.
##[debug]Processed: ##vso[task.logissue type=error]Cmd.exe exited with code '1'.
##[debug]Processed: ##vso[task.complete result=Failed]Error detected
##[debug]Leaving C:\build\_work\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.212.0\cmdline.ps1.
Finishing: Invoke NUKE build
Nuke project:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net8.0</TargetFramework>
<RootNamespace/>
<!-- CS649: Field may not be assigned because it is injected by NUKE -->
<NoWarn>$(NoWarn);CS0649</NoWarn>
<NukeRootDirectory>..</NukeRootDirectory>
<NukeScriptDirectory>..</NukeScriptDirectory>
<EnableUnsafeBinaryFormatterSerialization>true</EnableUnsafeBinaryFormatterSerialization>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Nuke.Common" Version="8.0.0" />
<PackageReference Include="Nuke.Components" Version="8.0.0" />
</ItemGroup>
<ItemGroup>
<PackageDownload Include="coverlet.console" Version="[3.1.2]"/>
<PackageDownload Include="dotnet-coverage" Version="[17.10.2]"/>
<PackageDownload Include="dotnet-sonarscanner" Version="[8.0.3]"/>
<PackageDownload Include="GitVersion.Tool" Version="[5.12.0]"/>
<PackageDownload Include="ReportGenerator " Version="[5.2.1]"/>
</ItemGroup>
</Project>
Hey @lg2de, %tmp%\.sonarqube\resources is used to download the analyzers from the server. The intend is to cache them, so they don’t need to be downloaded again for each analysis.
SonarAnalyzer.Security.dll is the analyzer for the C# Security rules. These are not available in the Community Edition of SonarQube. Are you connecting to different SonarQube servers with different editions by any chance?
Let me know, if this information helps you to investigate the issuer further.
Yes, we are using a server with Community Edition and a second one with Developer Edition.
The build agents covers several projects which are spread over the two SQ server.
It is fine to cache the files. The problem is, we feel this is not working correctly when using the package dotnet-sonarscanner to update the cache if necessary.
So far, we have a work-around to run a build using the old analyzer before a build with the new one is working fine. The old analyzer seems to download the files correctly, the new one not.
Further, I’m not sure whether the problem is really affecting only the file SonarAnalyzer.Security.dll. In my initial report I listed only one error message because I thought it is sufficient.
Here are error messages from another failed run:
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\0\Google.Protobuf.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\0\SonarAnalyzer.CFG.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\0\SonarAnalyzer.CSharp.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\0\SonarAnalyzer.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\1\Google.Protobuf.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\1\SonarAnalyzer.CFG.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\1\SonarAnalyzer.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
CSC : error CS0006: Metadata file 'C:\Users\***\AppData\Local\Temp\.sonarqube\resources\1\SonarAnalyzer.VisualBasic.dll' could not be found [C:\build\_work\1400\s\build\nuke\nuke.csproj]
The problem always starts with removing the TEMP folder. For general cleanup the build servers removes the folder weekly automatically. As a work-around after removing the TEMP we run the old build definition which creates the .sonarqube folder.
The error message is not created with the BEGIN step, but while compilation of the NUKE project before BEGIN.
I do not know how to do this! The automatic build fails already before I can run BEGIN.
This is why I’m wondering how the compilation of the project can cause this error message.
Ah, I think I now understand the problem. I’m unfamiliar with NUKE, but is this the order of the steps?
Build NUKE project
BEGIN
Build business project
END
If so, I suspect that the NUKE project build picks up the sonar configuration of the business project build, which breaks expectations. How it works is that the scanner puts this file in the machines ImportBefore folder. This causes every build to check for a local .sonarqube folder. If one is found, it looks for the analyzers on disk to include them in the build.
I suspect the NUKE project picks up the business project’s .sonarqube folder and then fails to locate the files on disk. Do you build the NUKE project from the same folder as the business project? Can you separate them?
I cannot separate them. It is intention of a NUKE build to be part of the business code base.
In one of my earlier messages in this thread I listed several folders I found. Could you please explain what the intention of these folders are and how they are maintained (setup, cleanup)?
One solution that comes to mind is to delete the .sonareqube folder at the project’s root before the NUKE build. Can you try and see if that resolves the problem?
The first one is created and filled during the BEGIN step. It contains the analyzers for the build. It is usually not cleaned up to avoid re-downloading the same files over and over.
For the other two I need to dig deeper, since I don’t know from the top of my head.
This implies, I do not get analyzed the NUKE project. But this is not correct.
Also the build should be defined in clean code.
Depending on the final result of your analysis of the remaining .sonar* folders I currently think the workflow overall has some gaps. Assumptions between the different folders seems not to be consistent.
If you want to analyze the NUKE project build, you need to run it after the BEGIN step. If there is a left over .sonarqube folder from a previous run, not running the BEGIN step before, can lead to unintended consequences like the ones you have encountered.
) and b) I can’t answer these questions myself, and I can’t refer them to people who will have to go spelunking in old code to dig up the answers.