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

SonarQube Cloud
, ,
41

Hi, use version 5, works just fine.

42

Hello y’all,

Thank you all for your prompt notifications and feedback. We just pushed a fix to both extensions (SonarQube, SonarCloud). It seems that the issue is fixed on our side.

Can you please verify that extensions for SonarQube v7.0.1 or SonarCloud v3.0.1 fixed the issue in your pipelines too?

Thank you for your help, and apologies for any inconvenience caused.

4 Likes
43

It seems to be working for us which is great.

Looking back, in Azure DevOps Extension (v3) failing (System.IO.FileLoadException) - #19 it seemed that Sonar was not aware of this issue until reported in this forum. Can you explain what steps you’ll be taking to identify this in-house next time to minimise customer downtime?

4 Likes
44

Hello,
Is there going to be a fix for v2 of SonarCloud? That way we can take time to update multiple pipelines to v3?

1 Like
45

My previous post is referring to the extension version as published on the marketplace.

So when upgrading to the SonarCloud extension v3.0.1, you will still have access to the tasks versions 2.3.4 which include the patch. Specifying @2 in your pipelines should now use 2.3.4.

To be more verbose:

  • For SonarCloud, the extension version v3.0.1 contains:
    • The major task versions @3 (3.0.1)
    • The major task versions @2 (2.3.4) (now deprecated)
    • The major task versions @1 (1.41.1) (now deprecated)
  • For SonarQube, the extension version v7.0.1 contains:
    • The major task versions @7 (7.0.1)
    • The major task versions @6 (6.3.4) (now deprecated)
    • The major task versions @5 (5.19.2) (now deprecated)
    • The major task versions @4 were deleted starting from v7.0.0
2 Likes
46

When we were still using v2 of the sonarcloud tasks, e.g. SonarCloudPrepare@2, it should have continued to use v2.3.4 right? why was it using v3.0.0 and failing?

47

Ah. Thank you for the additional details!
When I replied it hadn’t updated to 2.3.4 but looks like it has caught up.

48

We are both testing the released extension in our pipelines and have integration tests in the extension.

The conditions for this issue are very specific:

  • Use Windows runners (not Unix)
  • Use SonarCloud V2 tasks (not V3 or V1)
  • use the embedded NET Framework Scanner (not specify dotnetScannerVersion)

Unfortunately, the tests we ran before releasing did not include this specific combination. We discovered the issue just after releasing because we are dogfooding the extension and our own pipelines have started failing.

We will hold a post-mortem before the end of the week to decide what actions to take to catch this earlier in the future. Thank you again for your reports.

I suspect, if you were pinging SonarCloudPrepare@2, you were automatically upgraded to version 2.3.3 of the tasks (not 3.0.0) which was not working. Now, you should have automatically moved to 2.3.4 which contains the patch.

3 Likes
49

How can we get 7.0.1 for an onpremise/hosted Azure DevOps? It seems marketplace is still showing 7.0.0 and it is not updated yet. Thanks!

50

Sorry, found it. Disregard the question!

51

Fix is working (SonarQube) for us thank you!

3 Likes
52

7.0.1 is not working for us.

I get another error:

Starting: Sonar | Prepare
==============================================================================
Task         : Prepare Analysis Configuration
Description  : Prepare SonarQube analysis configuration
Version      : 7.0.1
Author       : sonarsource
Help         : [More Information](https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/scanners/sonarqube-extension-for-azure-devops/)
==============================================================================
##[warning]Can't find loc string for key: LIB_InputRequired
##[error][ERROR] SonarQube: Error while executing task Prepare: LIB_InputRequired SonarQube
##[error]LIB_InputRequired SonarQube
Finishing: Sonar | Prepare

    - task: SonarQubePrepare@7
      displayName: Sonar | Prepare
      inputs:
        SonarQube: ${{parameters.SonarConnection}}
        scannerMode: 'CLI'
        configMode: 'manual'
        cliProjectKey: ${{parameters.SonarProject}}
        cliProjectName: ${{parameters.SonarProject}}
        cliSources: $(System.DefaultWorkingDirectory)
        extraProperties: |
          sonar.verbose=true
          sonar.log.level=TRACE
          sonar.projectVersion="$(Build.BuildNumber)"
53

Hi,

Is there any kind of cache you can clear?

 
Ann

54

This job is running on MS Hosted Agents, so I don’t think so.

Starting: Initialize job

Agent name: 'Hosted Agent'

Agent machine name: 'fv-az1013-269'

Current agent version: '3.245.0'

Operating System

Ubuntu

22.04.5

LTS

Runner Image

Image: ubuntu-22.04

Version: 20241015.1.0

Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20241015.1/images/ubuntu/Ubuntu2204-Readme.md

Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20241015.1

Runner Image Provisioner

2.0.384.1

Current image version: '20241015.1.0'

Agent running as: 'vsts'
56

We are continuing to have this issue. The error message is 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)

Our task looks like this, except that “Project Name” is the real name of our project, “Project Key” is our real project key, and “Organization Name” is the real name of our organization:

- task: SonarCloudPrepare@3
  inputs:
    SonarCloud: 'SonarCloud - Project Name'
    organization: 'Organization Name'
    scannerMode: 'dotnet'
    projectKey: 'Project Key'
    projectName: 'Project Name'
    projectVersion: '$(Build.BuildNumber)'
    extraProperties: |
        sonar.projectBaseDir=$(System.DefaultWorkingDirectory)/
1 Like
57

Sorry for the confusion. We migrated our CI templates today at the same time you were performing the update and it turned out the SonarQube parameter was just null but that was an error on our side.

2 Likes
58

7.0.1 is working for us, but we needed to change the scanner type from MSBuild to dotnet for some reason. Doing so enable lots of more sensors we were not using under 6.x including the following. Any ideas as why this needs dotnet and not msbuild and why all these new sensors are being used now?
2024-10-21T19:55:18.6655566Z INFO: Sensor PL/SQL Sensor [plsql] 2024-10-21T19:55:18.6656016Z INFO: Sensor PL/SQL Sensor is restricted to changed files only 2024-10-21T19:55:35.4538673Z WARN: Invalid character encountered in file E:/bld02resware4/_work/1/s/ResWareSQL/PopulateResWareDB.sql at line 6171 for encoding UTF-8. Please fix file content or configure the encoding to be used using property 'sonar.sourceEncoding'.

59

The issue is fixed.

60

We’re still experiencing the same issue today. We’ve updated our tasks to version 3. But we’re still getting the same error when we come to the SonarCloudPrepare task.

##[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 only workaround we’ve found is the one mentioned above where you designate a specific version of the dotnetScannerVersion.

61

The issue is fixed for us too.

1 Like