Do not generate module related properties in sonar-project.properties

[sebastien-marichal]

Since SonarQube 7.6, modules are deprecated.
Right now, for each project .csproj, we still generate module related properties:

sonar.projectKey=exclusion
sonar.working.directory=C:\\projects\\Exclusion\\.sonarqube\\out\\.sonar
sonar.projectBaseDir=C:\\projects\\Exclusion
sonar.pullrequest.cache.basepath=C:\\projects\\Exclusion

615D01B7-CB50-4152-8998-434C1ABC3516.sonar.projectKey=exclusion:615D01B7-CB50-4152-8998-434C1ABC3516  # This is deprecated
615D01B7-CB50-4152-8998-434C1ABC3516.sonar.projectName=Exclusion  # This is deprecated
615D01B7-CB50-4152-8998-434C1ABC3516.sonar.projectBaseDir=C:\\projects\\Exclusion  # This is deprecated
615D01B7-CB50-4152-8998-434C1ABC3516.sonar.sourceEncoding=utf-8  # This is deprecated
615D01B7-CB50-4152-8998-434C1ABC3516.sonar.sources=\  # This is deprecated
"C:\\projects\\Exclusion\\Program.cs",\
"C:\\projects\\Exclusion\\web-client\\src\\app\\s\\p.service.spec.ts"

615D01B7-CB50-4152-8998-434C1ABC3516.sonar.test.inclusions=**/*.spec.ts  # This is deprecated
615D01B7-CB50-4152-8998-434C1ABC3516.sonar.cs.analyzer.projectOutPaths=\  # This is deprecated
"C:\\projects\\Exclusion\\.sonarqube\\out\\0"
615D01B7-CB50-4152-8998-434C1ABC3516.sonar.cs.roslyn.reportFilePaths=\  # This is deprecated
"C:\\projects\\Exclusion\\.sonarqube\\out\\0\\Issues.json"

615D01B7-CB50-4152-8998-434C1ABC3516.sonar.working.directory=C:\\projects\\Exclusion\\.sonarqube\\out\\.sonar\\mod0  # This is deprecated
sonar.visualstudio.enable=false

sonar.modules=615D01B7-CB50-4152-8998-434C1ABC3516 # This is deprecated

While it still works, there are properties that can sometimes generate warnings that confuse users, such as reported here.

The previous example will generate the following warning when invoking the scanner-cli during the end step:

WARN: Specifying module-relative paths at project level in the property 'sonar.exclusions' is deprecated. To continue matching files like 'web-client/src/app/s/p.service.spec.ts', update this property so that patterns refer to project-relative paths.

Which is due to the 615D01B7-CB50-4152-8998-434C1ABC3516.sonar.test.inclusions property in the file.

Known workaround

Do not set properties in the csproj but as a CLI parameter.

For the example above:

dotnet sonarscanner begin /k:<project-key> /d:sonar.token=<sq-token> /d:sonar.test.inclusions=**/*.spec.ts

[andrei-epure-sonarsource]

We would need to double-check that everything works as expected when not generating these properties.

For example, we need some project-level properties, which refer to modules in scanner terminology (e.g. TEST vs MAIN categorization).

Also see https://sonarsource.atlassian.net/browse/SONAR-13756

[luiz-soares]

Hi, I'm the one which initially reported this.

tl;dr
The suggested workaround doesn't work the same way to me. My concern is that the fix for this issue is to stop supporting properties at csproj/project level, what would break the only way I found to get it working.

long story:

This is a solution containing multiple projects, one for the frontend (javascript/ts), couple .NET libraries, test projects and an asp.net application. Such frontend projects exists solely for Sonarcloud, to capture both backend/frontend with one msbuild scan.

sonar.test.inclusion and sonar.test are only set within csproj of the frontend project, because sonarcloud doesn't take .spec. files as test code by default. Different from a 'backend' .NET project, where all tests are inside a test project, with javascript, tests are along-side their 'tested component', so I cannot classify the whole project as a test or main.

For all other (.NET) projects, the classification done by Sonarcloud is fine and works.

When I remove both settings from the project file and set sonar.test.inclusions globally, using extraProperties of SonarCloudPrepare Azure DevOps Task, things break:

• .NET Test projects doesn't appear at all in Sonarcloud's Code tab (previously they appeared but with no lines of code, as expected)
• The files matched by sonar.test.inclusions are also missing (previously they appeared but with no lines of code, as expected)

If I also set sonar.test globally pointing to my Repository root globally, analysis fail saying .spec. files were added twice:

ERROR: File .../p.spec.ts can't be indexed twice. Please check that inclusion/exclusion patterns produce disjoint sets for main and test files

It seems to be related to the fact that all projects then look at the Repo root (a folder above them) for test context and ends up matching files twice.

I also tried with sonar.test.inclusions globally, and sonar.test inside csproj, but that had similar results to the first attempt I mentioned.

[pavel-mikula-sonarsource]

We cannot simply remove this. While modules were deprecated on the Plugin API side, there's still nothing to replace the necessary functionality with.

Such a change would require thorough specification and prototyping.

As it would also immediately break support for the latest SQ LTS/LTA, especially on AzureDevOps side, we'd need to specify a strategy for that too.