Troubleshooting .NET analysis

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 SonarQube (Server, Cloud, IDE) product.

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:

• [Coverage & Test Data] Generate Reports for C#, VB.net: Get up to speed on how to import code coverage for your .NET project and troubleshoot unit test results and execution reporting.
• [Coverage] Troubleshooting guide for .NET code coverage import: The most frequent problems regarding code coverage import, each with suggested solutions.
• Finding logs about importing code coverage: Does your coverage data look wrong? Check the scanner logs first; here you’ll find details to investigate what each sensor has done during the import.
• Investigating the performance of your .NET analysis: This guide contains ten steps you can take to improve the performance of your analysis, as well as an introduction to what is happening in the analysis to guide your investigation.
• Configuration of WarninsAsErrors for .NET build: The SonarScanner overrides two properties affecting the behavior of warnings during the build. See this guide to understand how they can be configured in a project file. 

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 Server or SonarQube Cloud.

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 when triggering the build; 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.