Lines of code empty for Analisis Net framework 4.8 Code

SonarQube Cloud
, ,
1

Hi everyone,

Actually I am Analyzing projects .net framework with GitHub Actions.
I have a problem using the sonar-scanner-9.0.0.100868-net-framework client, this in order to analyze a .net framework 4.8 code, the CS lines of code are not analyzed and only duplicate code is displayed:

image
image1513Ă—546 33.4 KB

I share the logs of the analysis performed:
logs_30954215876.zip (59.4 KB)

Is something missing in the configuration the solution NET?

Thanks.

2

Hi Edwin,

Welcome to our community!

I checked the logs and from what I can see, although 14 projects are detected, the analyzers do not raise any issues. I would need more details to understand why. Would it be possible to share with us the logs in the verbose mode? You can enable verbose mode by using /d:sonar.verbose=true parameter when calling the scanner begin command.

3

Hi Costin,

Attached log with verbose=true

Thanks,

Edwin
logs_31084806316.zip (620.3 KB)

4

Hi Edwin,

Thanks for sharing the logs with us. I took a look and the problem is not obvious. We need to investigate further.

5

Hi Edwin,

Would it be possible to share the dotnet build logs in the binary format? You can generate the binary format by providing the -bl: parameter like so: dotnet build --no-incremental -nr:false -bl:build.binlog.

This will give us more insight into why the analyzers are not properly linked and executed during the build.

6

Hi Costin,

I attached log with command:

msbuild.exe DAV_MULTIVENDOR.sln -nologo -nr:false -p:DeployOnBuild=true -p:DeployDefaultTarget=WebPublish -p:WebPublishMethod=FileSystem -p:DeleteExistingFiles=True -p:configuration=Debug -p:UseAppHost=false -bl:build.binlog -t:Rebuild

Thanks.

logs_31184684861.zip (624.4 KB)

1 Like
7

Hi Edwin, I cannot find the build.binlog file in the archive.

8

Hi Costin,

Excusme, I shared build.binlog.

Regards,

Edwin
build.binlog.zip (533.1 KB)

10

Hi,

I’m sorry to get back to you and ask for more logs, but could you please share with us the .sonarqube folder generated after the project has been built?

For the run we have logs, it was generated to D:\a\davi-atm-multiservicios-mngr\davi-atm-multiservicios-mngr\NET\DAV_MULTIVENDOR\.sonarqube.

When checking the logs everything looks fine: the projects are categorized as MAIN code categorized as MAIN project (production code), the files are found for analysis Number of files to analyse: 70. and the analyzers are passed to the compiler /analyzer:...\SonarAnalyzer.CSharp.dll. At the same time, there are no sonar warnings raised and there are no lines of code reported, which means that the analyzers were not executed.

11

Hi Costin,

Attached .sonarqube folder.

Thanks for you help.

Regards,

.sonarqube.zip (9.3 MB)

12

HI Costin,

Do you have any update?

Thanks,

Edwin

13

Hi Edwin,

I was caught up with other tasks, and only now I found some time to take a look. From what I can see, the analyzer that is responsible for computing metrics was executed, but it generated data only for just a few files (like SharedAssemblyInfo.cs).

One reason this might happen is if the analyzer detects that the code is generated. Are any of the following attributes used in the code files?

  • DebuggerNonUserCode
  • DebuggerNonUserCodeAttribute
  • GeneratedCode
  • GeneratedCodeAttribute
  • CompilerGenerated
  • CompilerGeneratedAttribute

Or, do the files (maybe the headers) contain comments with the following strings:

  • “auto-generated”
  • “autogenerated”
  • “generated by”?

Any of these criteria might make the analyzer think that it’s analyzing generated code, which would lead to skipping the analysis.

One thing you might try (just for a test) is to enable generated code analysis

image
image1038Ă—724 53.3 KB

14

Hi Costin,

We enable Parameter(attache image). But the result is same.

Thanks for your help.

Edwin

image
image801Ă—505 48.2 KB

16

Just to double-check. Have you re-done the code analysis after the setting was enabled?

17

Hi Costin,

Yes, We done code analys after the settings those values.

Thanks.
Edwin

19

Hey there @edwin-avila_davicode !

I took a look at your problem as well and discussed it a bit with my colleague.
The reason this behavior is happening is because we are considering your analysis as an Incremental PR analysis.
This means that we are not analyzing all the files, but only the ones that have changed between the PR branch and the base branch. This happens for performance, so that the scan is faster, as a full-scan has to look into more finals and generate issues and metadata.

We noticed that it is not currently possible to disable this, so I made a ticket where you can track the effort.

What I am curious about is why you can see the files in the screenshot at all.
If the analysis is working as intended, then the files should not appear at the browser.
I have a couple of follow up questions for you:

  • Are the logs you send us happening in a PR? Or do they happen on a branch everytime someone merges, like for example master or a long-lived branch? From the logs, I think it is a PR, as GitHub Actions seem to be setting GITHUB_BASE_REF, which is a PR-exclusive environment variable.
  • Furthermore, could I please see your workflow YML file? If you are not comfortable with sharing the entire thing, I mostly care about the events part. For example:
on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
  • From where did you take the screenshot above? Can you send me the URL? Even if I cannot access it, I want to see which view you are looking at. And a bigger screenshot of the view would be appreciated, where I can see the header, like so:

image
image1572Ă—759 51.1 KB

21

Hi Gregory,

Sorry for the delay in the response:
Are the logs you send us happening in a PR? R/ Yes, these logs come from a PR, this pull request start YML secuence:

image
image1248Ă—618 15.1 KB

image
image1115Ă—524 14.3 KB

Build command:
msbuild.exe DAV_MULTIVENDOR.sln -nologo -nr:false -p:DeployOnBuild=true -p:DeployDefaultTarget=WebPublish -p:WebPublishMethod=FileSystem -p:DeleteExistingFiles=True -p:UseAppHost=false

I cannot share you the SONAR URL because you don’t have access. I send you the Sonar Analisis code screenshot:

image
image1724Ă—759 59.4 KB

image
image1568Ă—776 54.3 KB

Thank you a lot for you help.

Regards,

Edwin

22

Hey @edwin-avila_davicode

It’s funny you say that, because I went back to the first set of logs you shared and noticed that your scanner command explicitly sets sonar.branch.name.

2024-11-15T21:37:51.4497513Z + SonarScanner.MSBuild.exe begin /key:davi-atm-multiservicios-mngr /name:davi-atm-multiservicios-mngr /organization:davivienda-colombia -d:sonar.host.url=https://sonarcloud.io -d:sonar.login=*** -d:sonar.branch.name=integration -d:sonar.dotnet.excludeTestProjects=true

So what’s probably happening is that:

  • The analysis is triggered on a PR event, so the scanner attempts to use the analysis cache
  • This excludes many of your files from analysis because the cache is being used
  • The scanner is forced to use sonar.branch.name=integration, resulting in a branch analysis (rather than a PR analysis)
  • The analysis is submitted to SonarQube Cloud as a branch analysis using the PR cache, which results in the behavior you’re seeing.

The answer here is probably as simple as removing sonar.branch.name from your scanner command and letting the scanner auto-detect whether it should be analyzed as a PR or as a branch.

If you really want to preserve a branch analysis of the integration branch (to see the full results, not just what changed in a PR) , you could add integration to the branches you list under on: push: branches: of your GitHub Actions YML.