[Request For Feedback] C# Plugin 5.2

[Dinesh Bolkensteyn]

Hi all,

We'd like to release the SonarQube C# Plugin version 5.2.

What's new?

1. Issue suppression through [SuppressMessage] is now supported
2. All FxCop issues are imported in SonarQube, even the ones on fields which could not be mapped back to a specific file
3. Adds 6 new rules

This release closes the gap between the issues you see in Visual Studio and in SonarQube.

Release notes:

  C# Plugin 5.2: https://jira.sonarsource.com/jira/secure/ReleaseNote.jspa?projectId=10935&version=13051

  FxCop Library 1.4: https://jira.sonarsource.com/jira/secure/ReleaseNote.jspa?projectId=10939&version=12489

Download: https://github.com/SonarSource/sonar-csharp/releases/download/5.2-RC1/sonar-csharp-plugin-5.2-RC1.jar

Please send your feedback before or on Monday 25th of April.

Happy testing

Best regards,

Dinesh Bolkensteyn
www.SonarSource.com
twitter.com/DBolkensteyn

[David]

Hi Dinesh,

Sounds great but is there a way to pull up those suppressions as a filter or disable that feature.  We have (outsourced offshore) developers that like to pepper code with suppressions to get around Rules and avoid issues. Conceptually, just as 'Resolved Issues' can be reviewed in the platform being able to pull up all suppressions for review would help. To then be able to mark those suppressions reviewers disagree with by raising as manual issues will help.

David

[Mike Barry]

I agree with David here. Instead of silently not importing suppressed messages, how about importing them as wont fix with the justification text as the comment?

[Dinesh Bolkensteyn]

That's a very good idea indeed - however I don't think this is technically possible with the current state of SonarQube.

For example, when you use the "NOSONAR" comment marker in Java code, those issues are not created in a False Positive or Won't Fix state : they don't appear at all.

The Java plugin however comes with another, dedicated rule, to detect when this "NOSONAR" marker is used.

For C#, this could mean to create a new rule to detect usages of the [SuppressMessage] attribute - but I personally really prefer your suggestion, which enables one to still see the exact rules which triggered and the issue message.

David, Mike: Is this new behavior blocking for you? (in which case, please vote -1) Or is it be acceptable to go in production with this new behavior as it is, knowning that we'll work on this again in a future sprint?

[Freddy Mallet]

Hi @Mike and @David,

The ability to import any switched off issues in SonarQube is definitely a missing feature and this would be relevant for all languages.

Feel free to vote for https://jira.sonarsource.com/browse/MMF-144.

Thanks for your feedback

Freddy 

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/9d34dc2f-88b3-4e9e-8dbf-0ab4c37e3ecf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Freddy MALLET | SonarSource

Product Director & Co-Founder
http://sonarsource.com

[David]

@Freddy - I have voted for the feature but ideally the implementation should not introduce a new attribute or comment such as // NOSONAR.  We already have problems with inline comment based suppressions with code tools like resharper that we have to strip out. This is particularly acute with code that is later edited (the subsequent edit may make the problem worse that it was when the exclusion comment was first added, but because the comment is permanent bad edits are not detected); or when quality tools change many years after the comment was added and the codebase is left littered with this old metadata. Perhaps the server might cleverly retain such metadata so that code is not littered with code analysis metadata specific to manufacturers and subsequent edits don't retain the escape clause.  There is definitely a role for SonarLint here.

@Dinesh - I would never want to stand in the way of progress :) 

David

From our perspective source code with inline comments specific for code analysis tools is messy and when multiple manufacturers do it

[Mike Barry]

Thanks for pointing me at the MMF. I've voted for it. This seems like such a huge win from my perspective. To your point in the comments, this will allow users to bypass the admin issues permission. However they can already do that with NOSONAR and native suppression attributes. Even worse, these suppressions are not tracked. Auto closing would at least allow them to be tracked. If the issue was auto closed and we had the ability to search sonar for all auto closed issues it would go a long way ensuring that suppression doesn't get misused.

Thanks!
Mike

P.S. Depricating NOSONAR for languages that have native issue suppression should be mandatory:-)

[Dinesh Bolkensteyn]

Sounds like a good plan.

I am therefore closing this vote and will proceed with the release.

Dinesh Bolkensteyn
www.SonarSource.com
twitter.com/DBolkensteyn

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/0gghnIQf3XU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/0e6cf168-31ce-4728-9249-d36bce49ec32%40googlegroups.com.

[G. Ann Campbell]

Hi David,

You can think of //NOSONAR as a bit of our legacy code. Thus, we need to support it in the interim, while replacing it with language-native functionality, as you'll see in the ticket. :-)

Ann

[David]

Hi Ann,

Thanks for your note. Is there a way to disable //NOSONAR.  e.g. as a global option in the SonarQube UI?

David

[G. Ann Campbell]

There's not, but there is a Java rule to raise an issue on each use.

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/0gghnIQf3XU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/7488c576-5b41-4046-a3fa-97c1f7693b40%40googlegroups.com.