This is anoying in mult-language repositories. In a Java and C# repo we have Gradle build first and then the dotnet build. In Azure DevOps, only the C# Sonarqube issues are shown in the pull request, as they are seperate projects in SonarQube and the first result is removed when the second will comment. And some developers only will have a look in the PR, not on SonarQube. But I haven’t found a solution for an all-in-one SonarQube analysis yet 
2 Likes
Funnily enough I just asked support a question sort of related to this - we are starting to do “infrastructure as code” and want to keep the infrastructure for an app alongside the code - so the developers would develop say an azure service fabric C# application and write the terraform IAC to configure the SF cluster in azure and deploy the app to it.
How “safe” is the app and how good quality it is would seem to be a function of both the code AND the infrastructure - it’s all very well your application code being secure but if the infrastructure it is on is not secure then that doesn’t seem ideal.
So perhaps a slightly different use case than yours - I would like to see the analysis for both the code and the terraform scripts in the same Sonar project whereas you have separate projects in Sonar - but in both cases we have multiple analyses we want to run in the same repo and report it all somewhere.
I didn’t think of the CI integration - we will be using Github Actions so would want to see all the analysis results there too there…but conceptually similar to Azure DevOps.
I wonder if there is a way to use only the DOTNET scanner or only the CLI scanner to do all the analyses in one hit. I suspect not though since DOTNET seems to need a begin/end step whereas Java and others don’t have that - just a single “analyse” step…
@milbrandt Monorepo support should help you do that… but it’s available starting in Enterprise Edition and I think you use Developer Edition. (I would love to see a post in Product Manager for a Day about this 
)
Java + C# is a tricky combo since they both require a build. You would have to both reference the Java files in a project and manually supply the java-specifc build parameters (you might be able to infer the values by checking the Scanner Context of a background task submitted by the Scanner for Gradle)…
but in the end, I don’t like hacks like this.
@tbutler You might also be interested in these docs – if you can reference your IAC files in a .NET project, you should be able to get everything scanned by the Dotnet scanner.
Hi @Colin thanks for the link - it seems like the files need to be added to the VS solution.
We want to keep developer friction low - it seems unintuitive to add files to a build that are not part of that build and relies on “special” knowledge that these files have to be added if you want them to be analysed.
Engineers typically use VSCode to manage their terraform scripts rather than Visual Studio itself.
Speaking of Java - we had to use the CLI scanner and not maven integration for a repo that contained both Java code and a javascript/html app (no Java involved).
A suggestion from support was to create a parent maven project to contain both the java build and the web build but again, this is not particularly intuitive to the development team to have to do something like this - why are they getting maven involved in something they build with webpack?
So we use the CLI scanner and supply the sonar.java.binaries parameter to it…seems to work well enough and we get everything analysed.
I agree it’s not intuitive. This ticket has been floating around for five years… today!, and unfortunately we haven’t gotten anywhere.
If it works well and you don’t receieve any warnings about unresolved imports or missing dependencies… it’s a good option. We find a lot of users have trouble configuring this, or simply leave it misconfigured for a “good enough” analysis, so we encourage using the scanners integrated in the build tool.
I’m going to split the last few posts off into a new Discussion topic, since I think we’ve gone down a new path, but certainly one worth discussing 
1 Like
Hi Volker and Tony
Thanks for sharing this, I’m the PM responsible for the .NET Ecosystem and wanted to let you know that this is something we hope to tackle this year by making it easier to scan other languages using the Scanner for .NET. I’ll post something on this thread when there is an update.
Tom
2 Likes
Thanks @Tom_Howlett
yes, I had in my two projects with Java combined with either C# or C++ my problems to get everything working. In both cases I ended up with with two seperate analysis reports. Again, a mono-repo for languages in one application - JNI in case of C++ and protobuf messages in case of C# to message between both parts of the single application.
The case of different applications in one repo I didn’t had to analyze up to now.
@Colin I remember the discussions on the monorepo topic SonarQube Pull Request integration with mono-repositories where several others an I myself said we would need this for DE, not EE only. And unfortunately, the answer was obvious.
Hi @Tom_Howlett
Great to hear you will be looking at it this year - hopefully earlier rather than later in the year
I know at the moment one can add links to files into the .sln/.csproj file to get them analysed but I would hope this is not a requirement in the new world.
It is a non-intuitive process, manual, prone to being forgotten, and puts more burden on the developers.
They have no reason to add for example the IaC files for their app or .js files to a .cs project (or java files or python files) in order to work on that app so they are not likely to remember to do so just so the files can be analysed in SonarQube.
We would like the use of Sonar to be as invisible and friction-free as possible for our developers - they just work on their code as they always have done and if any analyses need to be run on the code, it just happens as if by magic.
The CLI scanner seems to work like this - it just analyses whatever it finds in the directory (and sub directories) you start it from.
It would be great if the dotnet scanner did the same.
3 Likes