Closed costin-zaharia-sonarsource closed 2 years ago
@costin-zaharia-sonarsource the different behaviour on Linux/Windows is surprising. According the logs in the other ticket, the analyzer settings are being removed in the Linux build because sonar.cs.roslyn.ignoreIssues=true
:
That is the expected behaviour (although it is arguably now incorrect because of source generators). Did you have this property set when reproducing the issue on Windows?
Did you have this property set when reproducing the issue on Windows?
No, on my run it was set to false.
sonar.cs.roslyn.ignoreIssues=false
Thanks, @duncanp-sonar. I've updated the title and the description.
Any update on this one, or can I help with a PR ?
Thanks!
i seem to be having the same problem on a linux build with sonar.cs.roslyn.ignoreIssues set to false. checking the binlog i can definately see my analyzer being removed and not re-added and i am setting /d:sonar.cs.roslyn.ignoreIssues=false when i execute dotnet-sonarscanner begin I can also see it is false in the LocalSettings section of .sonarqube/conf/SonarQubeAnalysisConfig.xml
Hi @digitalpowers
Could you please create a new thread on our community forum? This issue is related to code generators in the context when sonar.cs.roslyn.ignoreIssues
is set to true. The problem you're facing seems to be different.
Update: proposed solution:
Changes need to be synchronized with the analyzers.
Note: the proposed solution might also address #1211 - check whether #1211 is still an issue once this bug is fixed.
from discussion with @csaba-sagi-sonarsource and @tom-howlett-sonarsource
If we don't remove analyzers and filter on the SQ Plugin side:
The default behavior won't change at all. Some people are doing this.
If we don't update SQ but we update the scanner, 3rd party issues won't work anymore.
We need to have a fallback strategy for SQ LTS users who update the scanner.
sonar.cs.roslyn.importThirdPartyIssues = true by default
If both are mentioned:
importThirdPartyIssues
is taken in considerationCan we tell which version of SonarQube we are? If 9.6 - never remove analyzers. If before 9.6 - keep existing behavior. If SonarCloud - like SQ 9.6.
And log to the user that importThirdPartyIssues
is not supported before SQ 9.6.
DECISION: Option 2
Another discussion with @duncanp-sonar and @csaba-sagi-sonarsource
We can filter the external issue in the END step. This will avoid confusion and dependencies between releases sonar-dotnet and s4net.
Performance-wise we cannot do anything.
We prefer Option 3 now.
We've also discussed that:
Loading analyzers is a bit overkill from workflow POV. Technically, it's doable and we have the codebase on AutoScan side https://github.com/SonarSource/sonar-dotnet-autoscan/blob/master/AutoScan.NET/Roslyn/AnalyzerCache.cs https://github.com/SonarSource/sonar-dotnet-autoscan/blob/master/AutoScan.NET/Analysis.cs
@costin-zaharia-sonarsource Might you consider changing the title to use "source generators" instead of "code generators"? I think that's the official nomenclature for this feature 😄
Thanks! 🙂
This issue was originally reported on sonar-dotnet: https://github.com/SonarSource/sonar-dotnet/issues/5466
Reproduction steps
sonar.cs.roslyn.ignoreIssues
is set totrue
begin
stepdotnet build
-> this will fail with theCS8795
errorThis happens because
Microsoft.Extensions.Logging.Generators.dll
is not passed to the compiler.Looking at the binary logs, the
OriginalAnalyzers
parameter is:and the
OutputItems
parameter is:All the previous files were removed.
When
sonar.cs.roslyn.ignoreIssues
is set tofalse
:OriginalAnalyzers
OutputItems
:Versions used:
dotnet-sonarscanner 5.5.3 dotnet sdk 6.0.200 ubuntu-20.04 hosted on azure devops pipeline Binary logs: logs.zip