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


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 The device is not ready
	at java.base/ Method)
	at java.base/
	at java.base/
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser$Parser.handleSourceFileTag(
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser$Parser.dispatchTags(
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser$Parser.parse(
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser.accept(
	at org.sonar.plugins.dotnet.tests.VisualStudioCoverageXmlReportParser.accept(
	at org.sonar.plugins.dotnet.tests.CoverageCache.readCoverageFromCacheOrParse(
	at org.sonar.plugins.dotnet.tests.CoverageAggregator.mergeParsedCoverageWithAggregatedCoverage(
	at org.sonar.plugins.dotnet.tests.CoverageAggregator.aggregate(
	at org.sonar.plugins.dotnet.tests.CoverageAggregator.aggregate(
	at org.sonar.plugins.dotnet.tests.CoverageReportImportSensor.analyze(
	at org.sonar.plugins.dotnet.tests.CoverageReportImportSensor.execute(
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(
	at org.sonar.scanner.sensor.ProjectSensorsExecutor.execute(
	at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(
	at org.sonar.core.platform.SpringComponentContainer.startComponents(
	at org.sonar.core.platform.SpringComponentContainer.execute(
	at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(
	at org.sonar.core.platform.SpringComponentContainer.startComponents(
	at org.sonar.core.platform.SpringComponentContainer.execute(
	at org.sonar.batch.bootstrapper.Batch.doExecute(
	at org.sonar.batch.bootstrapper.Batch.execute(
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(
	at java.base/java.lang.reflect.Method.invoke(
	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(
	at jdk.proxy1/jdk.proxy1.$Proxy0.execute(Unknown Source)
	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(
	at org.sonarsource.scanner.api.EmbeddedScanner.execute(
	at org.sonarsource.scanner.cli.Main.execute(
	at org.sonarsource.scanner.cli.Main.execute(
	at org.sonarsource.scanner.cli.Main.main(

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?

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?

1 Like

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.

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 :crossed_fingers:)

@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.


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.

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

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

Hi again,

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

This is my current version.

Thanks to you, all for help.

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!

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

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.

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

1 Like

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