FXCop 1.4.1 plugin installation for Sonar 6.7 in order to accommodate quality profile (C#, VBNET) inherited from Sonar 5.6

[jennyfeng1]

Hey Daniel,
I am Jenny from JPMorgan Chase. How are you?

We are migrating from Sonar 5.6 to Sonar 6.7. During the process, I have downloaded quality profile of C# and VBNET from 5.6, installed sonar-fxcop-plugin-1.4.1.jar on Sonar 6.7 DEV box, and restored the same profile on 6.7. I see for C#, some rules have their categories changed.
C# -
on Sonar 5.6 - 209 active rules - all in Code Smell
on Sonar 6.5 - 209 active rules - Bug (87), Vulnerability (48), Code Smell (74)

VBNET -
on Sonar 5.6 - 209 active rules - all in Code Smell
on Sonar 6.5 - 209 active rules - all in Code Smell

Does it look correct to you?

What does this FXCop plugin do?
I see we have 233 rules inserted in rules table for C# and VBNET each.
Anything else/benefit does this FXCop provide?

So if we are going to install FxCop plugin on our Sonar 6.7 Production in order to accommodate the quality profile from 5.6, should we install this version sonar-fxcop-plugin-1.4.1.jar? Any suggestion?

Thanks
Jenny

[DanielHWe]

Hey Jenny,

the Plugin uses Microsofts FX Cop to scan the binaries with static code analyses rules. As Sonar Qube startet to define own rules they removed the FxCop support and give it as community plugin to git hub.

Before I started to maintain this community plugin I asked the same question (what to use) to sonar qube, here there answere:

We deprecated the FxCop support because we had a lot of trouble with FxCop lately and we were not able to produce precise results with it.
• FxCop was not updated for a while by Microsoft, and as a result, the latest language features (such as C# 6 features, but even earlier like async/await) are not properly supported. FxCop produces an XML analysis report, which we were parsing in C# plugin. However this report was missing some issue locations due to the new language features.
• Inside Visual Studio, FxCop is not as well integrated as Roslyn based analyzers. This meant that with SonarLint for Visual Studio Connected Mode, you couldn't get the FxCop issues, and as a result you would see different analysis results inside the IDE and in SonarQube.
These points led to the decision that we deprecated the FxCop support. At the same time, we understand that many of our users still rely on FxCop, therefore, we extracted the functionality into a dedicated community plugin.

For a long time, Microsoft is planning to move FxCop onto Roslyn. When this work is done, you'll be able to use the SonarQube Roslyn SDK to generate a SonarQube plugin from FxCop. At the same time, as we realize that we can't wait for MS to do this work, we started analyzing what is our coverage over FxCop rules, and we'll work on lowering the size of the gap between the two products.

So to answer your question, we are working on the solution. However, right now you have to choose between the following options:
• use the community FxCop plugin,
• use only the C# plugin. (Internally at SonarSource we opted for this option)
I hope this answers your question,

In the meantime Microsoft published a static code analyse available as nuget packages (https://github.com/dotnet/roslyn-analyzers), but that is running during build so it is a big change in the plugin to use that instead of old fx cop.

[jennyfeng1]

Thank you so much Daniel. So is it best practice to use the rules set defined by Sonar? 'Sonar way'. What would you recommend for the quality profile for C# and VB.NET?

[DanielHWe]

We use both, I think it is up to you and your team what you use. As we decided, we did a check with "Sonar Way" and one with "Fx Cop" and checked the results and decided that we want to have some "Fx Cop" rules also checked, but that was an individual decision.