Troubleshooting
Knowing where to begin looking for information is the first step to reaching out for help. Many answers to commonly found problems can be found on the SonarQube for IDE channel of the Sonar Community Forum. See below for the basic steps to access the SonarQube for IDE logs when the analysis results are not what you expected.
Before posting to the Community, make sure that you have your logs ready by following the instructions below.
How to get the SonarQube for Visual Studio logs
- Select Show Logs from the SonarLint help menu: Extensions > SonarQube for Visual Studio > Help > Show Logs
To dig deeper, enable the Verbose output in the SonarLint Options, then repeat the action that caused the problem:
- Navigate to Extensions > SonarQube for Visual Studio > Options… > General and set your Logging level to Verbose.
Troubleshooting connected mode setup
No matching project found
No matching project is found because:
- It's best if you already have the project open in your IDE, otherwise SonarQube for Visual Studio might not be able to find a matching file.
- The current bound project or solution does not match the SonarQube Server or SonarQube Cloud project or solution. Please check your binding configuration.
If these solutions don't help, follow these instructions to manually configure the project binding.
No matching issue found
SonarQube for Visual Studio can't find your issue because:
- You might not be on the same branch.
- The issue was fixed, or the source code may be different from the analyzed version.
Updating your credentials
Unfortunately, you cannot update your SonarQube Server or SonarQube Cloud credentials in SonarQube for Visual Studio but the feature is in the development team’s backlog. Please see the Updating your credentials article on the Connection setup page.
Troubleshooting unexpected analysis results
Sometimes, issues found on the server differ from those found locally by SonarQube for IDE. Usually, the server-side rule configuration (your quality profile) is to blame; however, it could be something more than that. Maybe your local build configuration and system dependencies don’t align with your DevOps pipeline, or it could simply be that the issue, due to its complexity, is only detectable by SonarQube Server or SonarQube Cloud.
The collapsible below lists some of the most commonly encountered reasons, along with some details that will help you troubleshoot discrepancies.
Why your local analysis might be different than found on the server
Some issues might be detected by third-party analyzers
SonarQube for IDE will only run rules from SonarSource analyzers including custom rules extending SonarSource analyzers. Third-party analyzers usually have their own IDE integration, and there is no plan to run them inside of SonarQube for IDE.
Your test files might be mistaken as source files
Test files can be defined in SonarQube Server, on SonarQube Cloud, or in the IDE, and each IDE handles test files a bit differently. For example, SonarQube for Visual Studio does not distinguish between project and test code, and SonarQube for IntelliJ relies on the IDE to detect if a file is a test file.
In the case where the IntelliJ IDE detects the test file for SonarQube for IntelliJ:
- The file is under a test sources root. Those roots can be manually created by users or automatically populated by the IDE by relying on the build system such as Maven or Gradle, for example.
- The file is flagged as a test file by any plugin that you have installed. The IDE bundles some internal plugins like the “JavaScript and TypeScript” plugin; these internal plugins can infer if a file should be considered as a test file. Third-party plugins can also infer test files, and SonarQube for IDE will recognize these as such.
Some rules are too complex to run locally
Some rules can report issues at the project level or require extensive resources to analyze, such as injection vulnerabilities and some advanced bug detection rules; such issues are not displayed in SonarQube for IDE, only in SonarQube Server and SonarQube Cloud. Please check the SonarQube for IDE roadmap for a list of features and enhancements on the horizon.
File or language types are not supported
Check your IDE’s Rules and languages page for a list of supported languages and file types.
The analyzer version may be different
Improvements are constantly being made to the Sonar analyzers during the CI/CD development cycle. Depending on the product version you are running, you may have a different analyzer therefore, the results might be different.
- SonarQube Cloud is always running the latest analyzers.
- SonarQube Server and SonarQube Community Build runs the latest available analyzer at the time of its release.
- SonarQube for IDE runs the latest available analyzer at the time of its release.
- Sometimes SonarQube for IDE downloads and uses the same SonarQube Server or SonarQube Cloud analyzer when running in connected mode.
Your project configuration may be different
Discrepancies in C and C++ analysis may result from different project builds and system dependencies. For example, you might have one set up in your local build configuration and another set up for your CI build configuration (or the configuration created by Autoscan).
Language-specific examples
C or C++ Analysis
Troubleshooting C or C++ Analysis
You can create a reproducer file for C and C++ analysis that contains diagnostic information to help the developers at SonarSource investigate problems that occur in your analyses. Beginning in SonarQube for Visual Studio 8.10, the reproducer file may contain sensitive data about your machine's environment variables. *Please take this into account when sharing your files.
If you encounter a problem with C or C++ analysis, please contact us in the Sonar Community forum and include the reproducer file. Follow the instructions below for complete instructions on how to do this.
Creating a reproducer file for the Active Document
To create a reproducer:
- Open the C or C++ file that is not being analyzed correctly
- Open Visual Studio's Command Window, found under View > Other Windows > Command Window.
- Type in the command window:
Analyze.SonarLint.CFamily.CreateReproducer
You can then view the location of the created reproducer file(s) in the SonarQube for Visual Studio Output pane. Be certain to set your logging level to Verbose, and show the output from SonarQube for Visual Studio.
Notes:
- The reproducer file(s) are regenerated each time the command is invoked. Invoking the command will overwrite the previous reproducer file(s).
- Running the reproducer will only produce the reproducer file(s). It will not report any issues for the active C or C++ file, which might be helpful for your post to the Community or via your SonarQube support subscription.
Was this page helpful?