I have some custom Roslyn analyzers we want to upload onto our SonarQube server ( Version 9.0.1.46107, community edition)
We want to upload them with the Roslyn SDK to use Quality Profiles and we want to keep VB and C# consistent in our environment since people are using both.
Looking through the source code of the SDK in Argumentprocessor.cs (in RoslynPluginGenerator/CommandLine) I can see that there is a TODO to support multiple languages but that was added 6 years ago by the looks of it:
I am able to build another SDK version and it is able to find the VB.net analyzers and create jar files for them.
I can then upload them to my SonarQube server but they do not show up there under the VB.net rules
(If I switch the analyzer to a C# one, I am able to upload the jar files, and can see it reflected under the C# rules - I am following the same process for the VB rules so I believe this is something with the jar file).
Looking inside the jar file the SDK, that I switched to VB, creates the configuration.xml is referencing vb as the RepositoryLanguage.
So, the question is:
Are there any plans to add this functionality soon (possibly with the 3.0 release)?
Or, are there any additional ideas of what else needs to be changed for the VB version to work?
Also, note:
The only messages I have seen in the logs regarding this are these two but there are working C# rules that have corresponding messages so they shouldn’t be the problem
(Not sure where else to go for debugging information on the Server - any help with that would also be appreciated)
[o.s.u.c.UpdateCenter] The plugin ‘closeconnectioninfinallyblock’ version : 1.0.0 has not been found on the update center.
INFO web[o.s.s.p.ServerPluginManager] Deploy plugin CloseConnectionInFinallyBlock / 1.0.0 / null
[o.s.s.r.RegisterRules] Disable rule roslyn.closeconnectioninfinallyblock.cs:CloseConnectionInFinallyBlock
*This last one looks to be referring to the test C# one when I switched the analyzer type
As the .NET PM I can try and answer your first question - I am currently taking a fresh look at our support for 3rd party/custom Roslyn analysers with a view to making some improvements next year. It’s interesting to hear about your need for VB support. With that in mind can you tell me a bit more about what you use the customer analysers for? Do you use any 3rd party analysers with SonarQube and if so which ones?
@duncanp may be along shortly to answer your second question about what else needs to change for the VB version to work
We are fairly new to using SonarQube right now so the only custom/3rd party analyzers we are using are these Roslyn analyzers (our environment is pretty heavily .Net based). I did also make a few custom rules using templates/XPath for XML.
I am mainly just trying to remove as much of the manual code review process as possible (we are running SonarQube analysis from Azure DevOps pipelines). We have some standards laid out and we are converting those into SonarQube rules in the places were there is not already an overlapping built-in rule. For example, making sure we are following our specific naming standards, making sure that specific security tools are implemented in the application when needed, or making sure developers haven’t disabled all warnings in their projects.
@dashaw there’s a bug in the SDK code - the language key for Visual Basic.NET is wrong here. It should be vbnet.
The language key vb is for VB6 (so if you look in your SonarQube rules instance you should see your customer rules listed under VB6 rather than VB.NET).
I’ve tested locally that changing that value and rebuilding the SDK is enough to create a jar that shows the custom rules for VB.NET. However, I haven’t tried and end-to-end analysis. As explained in the blog post linked to in the Readme.md overview, the end-to-end analysis depends on the SonarScanner for .NET doing the right thing with custom analyzers downloaded from the servers. I can’t think of any reason why the scanner wouldn’t work with VB.NET analyzers in the same way it works for C# analyzers, but I haven’t tried it.
We made the change you suggested, re-built, and everything is working for us.
We were able to create the jar files, upload them onto the SonarQube server, and they have correctly analyzed the files, finding issues where expected.
