Missing blame information for AssemblyInfo.cs in Azure DevOps

Versions used

  • SonarQube: 6.0
  • Azure DevOps tasks:
    • Prepare Analysis Configuration: 4.4.1
    • Run Code Analysis: 4.4.1
    • Publish Quality Gate Result: 4.3.0

Error observed

On the Run Code Analysis task, I see the following warning for every AssemblyInfo.cs file in the repository:

17:56:25.563 WARN: Missing blame information for the following files:
17:56:25.563 WARN: * G:/a/ppe1a1/w/15/s/ProjectPath/Properties/AssemblyInfo.cs
17:56:25.563 WARN: This may lead to missing/broken features in SonarQube

Steps to reproduce

Our build is running in Azure DevOps with the following tasks, in this order:

  1. Version Assemblies (1.42.2)
  2. Prepare Analysis Configuration (1.4.1)
  3. Visual Studio Build (1.126.0)
  4. Visual Studio Test (2.141.9)
  5. Run Code Analysis (4.4.1)
  6. Publish Quality Gate Result (4.3.0)

On every build, we get Missing blame information files: … AssemblyInfo.cs warnings for every AssemblyInfo.cs in the repository on the Run Code Analysis task. I believe it’s because the Version Assemblies task is updating all of the AssemblyInfo.cs files in the repository, and the Run Code Analysis task is confused by the unstaged changes in Git.

Potential workaround

Two options:

  1. Disable the Version Assemblies task.
  2. Run the build twice Visual Studio Build task twice like so:
    a. Prepare Analysis Configuration
    b. Visual Studio Build
    c. Visual Studio Test
    d. Run Code Analysis
    e. Publish Quality Gate Result
    f. Version Assemblies
    g. Visual Studio Build

Neither are ideal: we lose assembly versioning with the first option, and our build times increase with the second.

Hi,

I have experienced the same issue, amongst others. Have you heard anything back on this?

Do you think we could perhaps just exclude the assembly file from the analysis using the advanced sonar.exclusions in VSTS?

Thanks, Andrew.

Nope, I never heard anything back. I’m no longer on that project or using SonarQube so I can’t say whether that’d work. Give it a try and let us know!

Yes, that is most likely the reason the problem happens.

And yes, that is a good workaround if you don’t care to analyze the assembly files. :heavy_check_mark:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.