Start Free
10.7 | Analyzing source code | .NET environments | Troubleshooting

Troubleshooting .NET analysis

On this page

Knowing where to begin looking for information is the first step to reaching out for help. Most commonly found problems have already been solved and their answers can be found on a Sonar Community Forum channel dedicated to your product (SonarLint, SonarCloud, and SonarQube).

See below for an overview of community guides written for .NET projects and a short list of some known issues.

Community guides

These guides are written with a less formal approach than our product documentation, investigating unique use cases with lists of potential problems and possible solutions:

Other possible problems

No coverage information for .NET Core reports

Description: Your code coverage is correctly configured for a .NET Core project and the scanner finds and processes coverage reports, but no coverage information is shown in SonarQube or SonarCloud.

Possible causes: VSTest issue 800: Code coverage requires DebugType full

Possible solution: Check that the DebugType property is set to Full in the project file.

Using multiple versions of the same SonarScanner

Description: If you are running multiple scans sequentially using different versions (.NET, .NET Core, .NET Framework) of the SonarScanner for .NET, you might see an error message like the following:

SonarScanner for MSBuild 5.0.4
Using the .NET Framework version of the Scanner for MSBuild
Pre-processing started.
Preparing working directories...
Cannot copy a different version of the SonarScanner for MSBuild assemblies because they are used by a running MSBuild/.Net Core process. To resolve this problem try one of the following:
- Analyze this project using the same version of SonarScanner for MSBuild
- Build your project with the '/nr:false' switch
Pre-processing failed. Exit code: 1

In this scenario, each .NET FX scanner version is considered to be a different version from the .NET Core scanner version. The assembly’s files on the disc are, in fact, different, even if the release version number is the same ("v5.0.4" in the example above).

Root cause: By default, MSBuild leaves a build server process running for a certain amount of time after a build completes (based on observation, this is around twenty minutes). This is a performance optimization so subsequent builds can be faster; the process is locking the scanner files, leading to the error message.

Solution: Building with /nr:false tells MSBuild not to use the build server for the build being triggered; it will prevent the files from being locked after the build has finished. If you regularly see this error in your CI builds, you can consider passing the /nr:false option to the MSBuild/dotnet command when triggering the build.

Note: Passing /nr:false won't shut down a build server that is already running. If you want to forcibly close a running build server, use the following commands:

  • the dotnet build server can be shut down using the command dotnet build-server shutdown.
  • the NET FX MSBuild server can be shut down using the command vbcscompiler.exe -shutdown.

Was this page helpful?

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License