C# Analysis takes a long time and does not end


I attach the log after cancel de build.error.log (1.8 MB)

Hi @omoreno

We’ve had many performance improvements since sonar-csharp 8.6.1. The latest significant improvement is in 8.13.1. We encourage you to update the plugin version from the SonarQube Marketplace, and see if it reproduces.

Hi Andrei,
thanks for the reply.

I saw the update, but I saw that it is mandatory update the instance.

Do yo know if 8.13.1 is compatible with SonarQube 7.9.1? I’m waiting to update when the new LTS will be available.

Kind regards

I apologize for my previous misleading message. Indeed, we recently made a decision about New language features now available exclusively in latest SonarQube versions, which applies for the ongoing LTS as well.

Can you please try with S4487 in addition to S1144 (it’s a similar rule)? I suspect this is the culprit.

If that doesn’t work, try disabling S3655, S3966, S3900 or S1944? Another idea would be S1128 (unused usings).

Please let me know which of these rules are the culprit. Because your analysis doesn’t end, this is the only way to see the rule with the problem.

When you’ll tell us what rule has the problem, we can take a decision whether to patch the LTS or not. Thank you.

Hi Andrei,
solved.

I have disabled S3966 and S1944 because S4487, S3655 and S3900 were not enabled, and I can build now.

I will make more test to confirm you which one has the problem.

Kind regards

Hi Andrei,
finally, after several tests, I have disabled the following rules to build:

  • S4158: Null pointers should not be dereferenced
  • S3655: Conditionally executed code should be reachable
  • S2589: Boolean expressions should not be gratuitous
  • S2583: Empty nullable value should not be accessed
  • S2259: Empty collections should not be accessed or iterated

Hope this can help you.

Thank you so much

Kind regards

Hi @omoreno

Thank you, and I am sorry that you need to disable all these valuable rules for the build to work. If you have time, I would be interested if you can narrow down the problem to one of these rules (or is it that all these rules must be disabled for the build to run)?

We would really be interested to narrow the problem more, so we can investigate and fix the underlying issue. Does the project that didn’t end the build before:

  • have huge files (tens of thousands of LOC)?
  • have huge methods (thousands of LOC)?
  • have any particular characteristic (we’ve seen problems with entity framework migration files before)?

Thanks a lot. If you want, we can continue this discussion on a private thread to avoid giving much details in the public.