SonarQube resolved if..elseif without code change(C126)

Hello please find the information regarding our system:

  • We are using SonarQube 9.9 and Sonarscanner for .net fw 5.11
  • SonarQube is deployed using zip

Recently SonarQube marked all the code smells with if…elseif(C# static code analysis: "if ... else if" constructs should end with "else" clauses) rule as fixed without any code change. We tried activating and reactivating that rule but that didn’t help. Please let me know how to fix this. If you need any logs , i would prefer to send them privately.

Thanks,
SK

Hi SK,

To be clear, these if...elseif trees all still need else clauses?

 
Ann

Hello,

Yes, we didn’t add any else clauses or do any changes to code. But Sonar without adding any else clauses has resolved all the issues.


As you can see on the above screenshots, it’s marked fixed and it’s for all the occurrence’s of this issues.

Thanks,
SK

1 Like

Hi SK,

Thanks for confirming. I’ve flagged this for more expert eyes.

 
Ann

Hello @sk2312,

Did this happen after you upgraded to SonarQube 9.9?
If yes, which version were you using before?

Also when you perform the build step - could you please check if the string warning S126 can be found in the output logs?

Thanks!
Best regards
Mary

Hi,

No this happened almost 8-9 days after we upgraded SonarQube 9.9. But regardless we were using SonarQube 9.8 before upgrading to 9.9.

And regarding buildlog, I did check throughly trying to look for that warning S126 but no it’s not present anymore there.

Thanks,
SK

Hello @sk2312,

Thank you for your answers.

One more question: which version of MSBuild do you use to build your projects?
You should be able to see this in the build logs right at the beginning of the build.

If you use MSBuild.exe to build your project you should see in the beginning of the logs:
Microsoft (R) Build Engine version x.x.x. for .NET Framework

If you use the dotnet CLI:
MSBuild version x.x.x.x for .NET

Hello,

The MSBuild version is 17.5.0+6f08c67f3 for .NET Framework.

Thanks,
SK

Hello @sk2312 and thanks for the quick response!

Would it be possible to use any MSBuild version before this and tell me if the issues re-appear? That’s what happened to me when I managed to reproduce your issue.

You can download for example VS 2022 build tools 17.4 from here Visual Studio 2022 Release History | Microsoft Learn.

Mary

Hello,

I will give it a try and let you know. I think this issue happened when we updated our build systems to 17.5 version so most probably this will fix the issue. But I would like to know if there’s a way to have latest MSBuild version and still fix this issue somehow?

Thanks,
SK

Hello @sk2312,

We are still investigating on our side, and so far the issue seems to be on MSBuild (in the new Roslyn version) and not in one of our products (which means that we should potentially report the bug and wait for a fix on the Microsoft side to use the latest MSBuild version).
I will let you know soon.

Thanks!

1 Like

Hello @sk2312,

After investigation, this seems to be a bug in Roslyn 4.5 (which is used in MSBuild 17.5.0).
Here is the issue we opened to them for you to follow.

Until this is fixed, the workaround is to use the previous MSBuild release to build your projects.

Best Regards
Mary

Hi,

Thanks for that. We were starting to see the same behavior with few other rules also but after going through your ticket guess it makes sense it’s not only C126 which is affected.

Regards,
SK

1 Like

@sk2312 I just tested MSBuild 17.6.0-preview-23081-04+7bf511372 and the issue seems to be fixed.
In case you update to the preview version please let me know if it works for you.

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

For anyone who comes to this thread searching for a solution - MSBuild version 17.5.1+f6fdcf537 contains the bug fix.

1 Like