Some issues are disappeared(mark as automatically closed(fixed)) after VS 2022 17.5.0 Upgrading

hakanaltindis · March 28, 2023, 5:33am

Hi,

We use SonarQube Developer Edition latest version which means 9.9 version. Visual Studio 2022 was upgraded to 17.5.0 at Feb 23, 2023. After this date, cognitive complexity issues were marked automatically as Close(Fixed). But issues still are in the code.

BTW, We use Azure DevOps pipelines. When I checked the log of the pipelines. I saw this exception in Run Code Anaylsis Step. This exception was thrown almost all lines.

WARN: Skipping the import of Visual Studio XML code coverage for the invalid file path: D:\a\1\s\Prometheus.NetStandard\SummaryImpl\SampleBuffer.cs at line 769866
java.io.IOException: The device is not ready
	at java.base/java.io.WinNTFileSystem.canonicalize0(Native Method)
	at java.base/java.io.WinNTFileSystem.canonicalize(WinNTFileSystem.java:465)
	at java.base/java.io.File.getCanonicalPath(File.java:626)
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser$Parser.handleSourceFileTag(VisualStudioCoverageXmlReportParser.java:110)
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser$Parser.dispatchTags(VisualStudioCoverageXmlReportParser.java:77)
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser$Parser.parse(VisualStudioCoverageXmlReportParser.java:63)
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser.accept(VisualStudioCoverageXmlReportParser.java:45)
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser.accept(VisualStudioCoverageXmlReportParser.java:32)
	at org.sonar.plugins.dotnet.tests.CoverageCache.readCoverageFromCacheOrParse(CoverageCache.java:39)
	at org.sonar.plugins.dotnet.tests.CoverageAggregator.mergeParsedCoverageWithAggregatedCoverage(CoverageAggregator.java:142)
	at org.sonar.plugins.dotnet.tests.CoverageAggregator.aggregate(CoverageAggregator.java:133)
	at org.sonar.plugins.dotnet.tests.CoverageAggregator.aggregate(CoverageAggregator.java:120)
	at org.sonar.plugins.dotnet.tests.CoverageReportImportSensor.analyze(CoverageReportImportSensor.java:92)
	at org.sonar.plugins.dotnet.tests.CoverageReportImportSensor.execute(CoverageReportImportSensor.java:84)
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
	at org.sonar.scanner.sensor.ProjectSensorsExecutor.execute(ProjectSensorsExecutor.java:52)
	at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(SpringProjectScanContainer.java:371)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
	at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(SpringGlobalContainer.java:137)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
	at jdk.proxy1/jdk.proxy1.$Proxy0.execute(Unknown Source)
	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)
	at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:126)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:81)
	at org.sonarsource.scanner.cli.Main.main(Main.java:62)

In my pipeline, Visual Studio Test step generate one .coverage file. In the next powershell step, we generate a new .coveragexml file. We use the below command

& C:\agent2\_work\_tool\VsTest\17.5.0\x64\tools\net462\Team Tools\Dynamic Code Coverage Tools\CodeCoverage.exe analyze /output:$(Agent.TempDirectory)\TestResults\CoverageResult.coveragexml C:\agent2\_work\_temp\TestResults\9cbd363e-9e76-41e0-ad3c-4524b98c1f71\filename_2023-03-28.06_57_15.coverage

After this command step, Sonarqube Code Analysis step runs and analyzes $(Agent.TempDirectory)\TestResults\CoverageResult.coveragexml file.

Before Visual Studio 2022 upgrading, The pipelines used old Code Coverage.exe. It was version 17.4.1

Our issue graph

So, what will we do to solve this problem?

anhaupt · March 28, 2023, 7:59am

We have a similar problem when analyzing our C# solutions. When we moved from dotnet 7.0.102 to 7.0.200 there are now less code smells reported. In particular, issues about Cognitive Complexity have disappeared. We are using SonarQube Enterprise Edition 8.9.10 and sonar-scanner-msbuild 5.12.0.
The problem persists with dotnet 7.0.202. When I switch back to dotnet 7.0.102 I receive again the code smells concerning Cognitive Complexity. Also the analysis time has reduced from by about 40 percent since we moved to dotnet 7.0.200. Seems like some analysis is skipped now?

Colin · March 28, 2023, 8:01am

Hey there.

Stepping away from the coverage issue for a moment, it sounds like you might be facing this issue we reported to Microsoft a few weeks ago.

github.com/dotnet/roslyn

Roslyn 4.5 does not enable DiagnosticAnalyzers via the ruleset file anymore

opened 08:42AM - 07 Mar 23 UTC

mary-georgiou-sonarsource

Area-Analyzers untriaged

**Version**: MSBuild version 17.5.0+6f08c67f3 - Roslyn 4.5 In [sonar-dotnet](…https://github.com/SonarSource/sonar-dotnet/tree/master) we have a set of analyzers enabled by default and a set of analyzers that need to be explicitly enabled by a `ruleset` file. Enabling by `ruleset` had been working as expected until the latest release of MSBuild 17.5. When our analyzers are used with MSBuild17.5 (Roslyn 4.5), all the rules not enabled by default are not executed, although they are enabled by a `.ruleset` file (which should have higher priority than the default values). During debugging - assuming we have enabled a suppressed analyzer with `DiagnosticId= "S126"` through a ruleset file: 1. When inspecting the `Compilation.Options.SpecificDiagnosticOptions`, the analyzer seemed enabled with value `{[S126, Warn]}`; however, it was not executed. 2. When the value of `IsEnabledByDefault` is manually set to true [when creating the DiagnosticDescriptor object](https://github.com/SonarSource/sonar-dotnet/blob/dffe8ff1aaeffb92431d5fa5e811c07b00da4808/analyzers/src/SonarAnalyzer.Common/DiagnosticAnalyzer/DiagnosticDescriptorFactory.cs#L45), then S126 was normally executed. 3. When the analyzer S126 is enabled through `.editorconfig,` it works as expected. 4. When we downgrade Roslyn to 4.4 - the ruleset enabling works as expected. The analyzers enabled by default are still properly disabled by the ruleset file. In summary - Roslyn does not take into account analyzers enabled through a ruleset file. I'll gladly provide any log or other info to help with the investigation.

For now, we would recommend downgrading to 17.4 until there is some resolution from Microsoft (the beta of 17.6.0 doesn’t demonstrate the issue, so fingers crossed )

@hakanaltindis Can you check if downgrading also fixes the coverage errors? That would help us understand more if it’s an issue with upgrading to 17.5.

hakanaltindis · March 28, 2023, 9:37am

Hi there,

Thanks both of you, @anhaupt and @Colin. I will check your solutions one by one.

Our project is a little big. A single analysis takes approximately 3 hours. So tests take a time.

But I will inform you from here.

Colin · March 28, 2023, 11:31am

Quick update: the issue may be fixed with v17.5.3 – we’re running some tests!

hakanaltindis · March 28, 2023, 12:13pm

I worked with latest version. But it did not work.

hakanaltindis · March 28, 2023, 4:30pm

Hi again,

I downgraded Visual Studio 2022 Build Tools. After that it worked successfully

This is my current version.

Thanks to you, all for help.

Colin · March 29, 2023, 8:33am

Thanks for the confirmation. We’ve confirmed on our side that there should be a fix in v17.5.4 of Visual Studio, release date TBD (maybe April 4th or 11th based on the release history).

It will also be fixed in v17.6 when it arrives.

This affected any analyzer that enabled non-default rules through a ruleset file, not just ours!

hakanaltindis · March 30, 2023, 7:18am

Thank you for info. I will test with new version as soon as possible.

Colin · April 12, 2023, 9:28am

Hey @hakanaltindis and @anhaupt

Visual Studio 17.5.4, released yesterday, should address the issue. Please let us know if you face the issue after upgrading.

anhaupt · April 17, 2023, 7:07am

I can confirm that in my case the problem has gone with dotnet 7.0.203 / Visual Studio 17.5.4. Thank you.

system · June 2, 2023, 10:59am

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.