The Scanner for MSBuild has two main goals :
- For solutions containing some C# and VB.Net: being fully integrated into the build system (MSBuild) to execute and configure SonarC# and SonarVB roslyn analyzers without having to update first any configuration file.
- For solutions containing some C#, VB.Net and/or C/C++: retrieving in SonarQube the logical structure of VS projects by associating each VS project to a SonarQube module.
But retrieving in SonarQube the logical structure of VS projects has a lot of possible bad side effects due to the flexibility offered by Visual Studio. Here are some examples:
- The same physical C++/C#/VB.Net source file can be part of three different VS projects in the same solution. Do we expect in such case to see three times the same file in SonarQube and so to count three times the issues/ncloc/... contained in this file ?
- Some C++ header files can be part of a VS solution and used by some nested VS C++ projects without being explicitly listed in those VS C++ projects (see shared directories). But yet we'd like to see them in SonarQube and track their code quality issues.
- Kind of variation of the first case : for the same set of source files we can have different similar VS projects targetting some different environments (OS for instance) and in such case all those source files are also duplicated in SonarQube.
The side effects are so important in C/C++ that we do consider to stop using the Scanner for MSBuild and use in place the Scanner CLI in order to retrieve in SonarQube the physical structure of source files. Nevertheless, this option for C/C++ would have a major drawback for solutions containing both C# and C++ source files : having to analyze twice the same solution and getting two SonarQube projects : one dedicated to the C# source files and the other one to the C++ source file.
The ultimate solution might be to stop having the Scanner for MSBuild feeding SonarQube with a logical structure of VS projects but in place with a physical structure of all files/directories. And in that case, the only remaining responsibility of the Scanner for MSBuild would be provide the smooth integration with the .Net build system. That would solve the bad side effects mentionned earlier.
The goal of this MMF is to provide a first experimental version of this analysis mode in order to get some answers to the following open questions :
- When we move from the default to the experimental analysis mode, and so when all the SonarQube modules are deleted, do we impact the behavior of the issue tracking mechanism ? In other words: does this lead to consider all the issues as being new ?
- When we stop having one SonarQube module for one Visual Studio project, is there any impact on the SonarLint Connected mode ? Are we able to match local issues with remote ones ?
- When the same C#/VB.Net source file is analyzed several times in different VS projects part of the same Visual Studio Solution are we able to easily merge the issues and measures available for this source file ? By taking for instance all distinct issues and the max of measures for a given metric ?
- Can it be disturbing for a .Net user to see in SonarQube the physical structure of files/directories and not the logical stucture of projects ?