C# analysis, deprecated plugins and SonarQube 6.0

377 views
Skip to first unread message

Giacomo Boccardo

unread,
Aug 6, 2016, 5:02:22 AM8/6/16
to SonarQube
I'm currently using the following plugin:

* C# 5.3.2
ReSharper 2.0
* StyleCop 1.1

C# is the only non deprecated plugin and StyleCop stopped working since SonarQube 6.0:

Exception in thread "main" java.lang.NoSuchMethodError: org.sonar.api.resources.File.fromIOFile(Ljava/io/File;Lorg/sonar/api/resources/Project;)Lorg/sonar/api/resources/File; at org.sonar.plugins.stylecop.FileProvider.fromIOFile(FileProvider.java:39)
[...]

Will this issue be fixed even on a deprecated plugin?

Am I supposed to remove the deprecated plugins? Considering the number of rules of each plugin, I don't think the official one (C#) has all the rules of the others.
In my opinion, a plugin should be deprecated only if there's an alternative.


Pascal Berger

unread,
Aug 7, 2016, 5:21:26 PM8/7/16
to SonarQube
 I already asked if there are plans to provide an official supported plugin of the StyleCop Roslyn Analyzers here: https://groups.google.com/forum/#!topic/sonarlint/vhw1hYB3mhI. Unfortunately without an answer.

G. Ann Campbell

unread,
Aug 8, 2016, 9:54:02 AM8/8/16
to SonarQube
Hi Guys,

With the SDK to build plugins for Roslyn Analyzers, you can wrap the StyleCop Roslyn-based analyzers into a plugin on your own, or maybe lobby the StyleCop team to do it.


Ann

Tamas Vajk

unread,
Aug 15, 2016, 7:54:31 AM8/15/16
to SonarQube, G. Ann Campbell
Hello Guys,

Just to add a couple of thoughts here: it's always a tough decision to deprecate a plugin, because there are people using it. There are many reasons though to deprecate them, but mostly it boils down to one: there's not enough added value provided by the plugin to justify the maintenance costs. We are focusing our new rules on bug detection and StyleCop is definitely not in that direction. And for ReSharper, I think the C# plugin covers most of the valuable rules there.

As Ann mentioned the Roslyn SDK is a way to fill this gap, but it's unclear who should do the necessary work. Generally wrapping a nuget package into a SonarQube plugin is easy, however extra care should be taken when rules have parameters (additional files in Roslyn terms). Some/Many (I don't know) StyleCop rules are parameterized (stylecop.json) and propagating the parameters from SonarQube to VS can't be done automatically. 

If you heavily rely on the deprecated StyleCop plugin, then another option is to say that you'd like to be the maintainer of it, and update the plugin to the latest SonarQube API. It's a small plugin as you can see here: https://github.com/SonarQubeCommunity/sonar-stylecop

Regards,
Tamas




Tamas VAJK | SonarSource
Language Team

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/59fb09e1-f78c-449f-957e-d55a81c33cb9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages