Azure DevOps Extension (v3) failing (System.IO.FileLoadException)

SonarQube Cloud
, ,
63

Hi,

@Shelly_Noll and @alexyoung can I get you to post your full analysis logs, please?

Share the Scanner for .NET verbose logs

  • Add /d:"sonar.verbose=true" to the…
    • SonarScanner.MSBuild.exe or dotnet sonarscanner begin command to get more detailed logs
      • For example: SonarScanner.MSBuild.exe begin /k:"MyProject" /d:"sonar.verbose=true"
    • “SonarQubePrepare” or “SonarCloudPrepare” task’s extraProperties argument if you are using Azure DevOps
      • For example:
        - task: SonarCloudPrepare@1
    inputs:
      SonarCloud: 'sonarcloud'
      organization: 'foo'
      scannerMode: 'MSBuild'
      projectKey: 'foo_sonar-scanning-someconsoleapp'
      projectName: 'sonar-scanning-someconsoleapp'
      extraProperties: |
        sonar.verbose=true
  • The important logs are in the END step (i.e. SonarQubeAnalyze / SonarCloudAnalyze / “Run Code Analysis”)

Share the msbuild detailed logs

MsBuild.exe /t:Rebuild /v:d

or

dotnet build -v:d

 
Thx,
Ann

64

Hi @Devin_Quince,

You may be interested in the announcement:

 
HTH,
Ann

65

Our pipeline doesn’t get to the SonarCloudAnalyze step. It’s failing on the SonarCloudPrepare step. It seems that I cannot paste the entire content of the step, but this is the part before the error. It’s not getting the 3.0.1 version even though that is what is installed on our tenant.

Starting: SonarCloudPrepare
==============================================================================
Task         : Prepare Analysis Configuration
Description  : Prepare SonarCloud analysis configuration
Version      : 3.0.0
Author       : sonarsource
Help         : [More Information](https://docs.sonarcloud.io/advanced-setup/ci-based-analysis/sonarcloud-extension-for-azure-devops/)
==============================================================================
[INFO]  SonarCloud: Server version: 8.0.0.57101
[INFO]  SonarCloud: Default branch of this repository is 'refs/heads/main'
D:\a\_tasks\SonarCloudPrepare_14d9cde6-c1da-4d55-aa01-2965cd301255\3.0.0\classic-sonar-scanner-msbuild\SonarScanner.MSBuild.exe begin /
SonarScanner for MSBuild 6.2
Using the .NET Framework version of the Scanner for MSBuild
Pre-processing started.

##[error]Unhandled Exception:
##[error]System.IO.FileLoadException: Could not load file or assembly 'SonarScanner.MSBuild.PreProcessor, Version=6.2.0.0, Culture=neutral, PublicKeyToken=c5b62af9de6d7244' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at SonarScanner.MSBuild.BootstrapperClass.<PreProcess>d__9.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at SonarScanner.MSBuild.BootstrapperClass.PreProcess()
   at SonarScanner.MSBuild.BootstrapperClass.<Execute>d__8.MoveNext()
66

We fixed it by adding dotnetScannerVersion: ‘9.0.0.100868’ to our SonarCloudPrepare@3 task. I don’t love this fix though because I assume we will have to manually update all of our pipelines each time there is a new version released? Is there a way to specify that it should always take the latest?

1 Like
67

Similar to others, we have had to pin the dotnetScannerVersion in the task.

This issue doesn’t seem to affect our API applications, only applications where SonarCloudPrepare says Using the .NET Framework version of the Scanner for MSBuild - where for some reason it decides the scanner version it needs is 6.2.0.0 instead of 9.0.0.100868.

68

Hi Ann, the 3.0.1 release has resolved our issue and we no longer need to specify the dotnetScannerVersion.

Thanks

1 Like
69

Further to this, I have noticed that the failed build were downloading v3.0.0 of the plugin.

I assume the ongoing issues for us may therefor be caused by some sort of caching? For reference, we are ADO Pipelines with SonarCloud as the target on hosted agents. v3.0.1 has been showing as installed all day but only v3.0.0 seemed to be loading into the build environment.

I’ve got a project which was failing earlier. I will run a build again and see if it is picking up v3.0.1 and passing.

1 Like
71

Moved to the correct spot for replying
I noticed that when I started using @7, my code coverage dropped to zero and the number of files to cover dropped by ~190K files. My new prepare task is

    - task: SonarQubePrepare@7
      inputs:
        SonarQube: 'Sonarqube - OnPremises'
        scannerMode: 'dotnet'
        projectKey: '***'
        projectName: '***'
        projectVersion: '$(Build.BuildNumber)'
        extraProperties: |
          'sonar.cs.dotcover.reportsPaths="c:\sonarqube\output_trunk\***.html"'
          sonar.scanner.scanAll=false

My old task is

    - task: SonarQubePrepare@6
      inputs:
        SonarQube: 'Sonarqube - OnPremises'
        scannerMode: 'MSBuild'
        projectKey: '**'
        projectName: '**'
        projectVersion: '$(Build.BuildNumber)'
        extraProperties: 'sonar.cs.dotcover.reportsPaths="c:\sonarqube\output_trunk\**.html"'

I was forced to use dotnet in @7, from msbuild. Could this be the issue and if so, why are we forced to do this if @6 is being deprecated in the future?

72

Hi @Devin_Quince,

That doesn’t sound normal. Let’s explore this in a new thread.

 
Thx,
Ann

73