This page is a work in progress. Do not hesitate to share your tips and tricks to improve this page.
If you encounter any trouble analyzing a C# project, first try to rerun the analysis adding "-X" to the command line in order to get a verbose output then ask for help to the users mailing list. Please do not open a JIRA ticket before sending emails to the users mailing list.
|Table of Contents|
succeeds but tests metrics do not appear
Obviously this happens when Gallio has failed during the sonar analysis. There are several possible causes, below a few of them:
- You are running the analysis on a 64b box using partcover. Please follow the FAQ page in order to solve the problem with command line corflag tool.
- The test framework used by the analyzed Visual Studio solution is incompatible with the version of Gallio used during the analysis. This happens if you are using a quite old version of Gallio with a brand new version of Nunit. Easy fix : upgrade Gallio.
- The coverage tool (i.e. NCover, Partcover...) has failed during test execution. Again check the verbose logs. Changing the gallio runner config property may help in this case.
For example, if you are using MsTest and if you get Microsoft.VisualStudio.TestTools.TestManagement.InvalidStorageExtensionException error messages, try to rerun the analysis setting property sonar.gallio.runner to IsolatedProcess (thanks mathieu Lagace for the tip)
succeeds but too few
issues are found
This often happens when the analysed Visual Studio solution has not Some tools like FxCop or Gendarme need compiled assemblies to perform analysis. In other words, they do not work on source code. Having too few issues most often comes from the following reasons:
- the Visual Studio solution hasn't been compiled prior to the
- SonarQube analysis - whereas this is clearly mentionned in the documentation that it should
- the solution has been compiled but the corresponding generated assemblies have been moved somewhere else (because of a specific build process) and SonarQube can't find them
- the solution has been compiled and the assemblies haven't been moved, but the whole solution folder has been moved to another location (and therefore the debug PDB files don't point to the original source locations)
Analysis succeeds but only one test assembly/project is taken into account
If you are using NCover, you may have purchase purchased the "Classic edition". Only the "Complete edition" allows to run tests from several assemblies and merge the coverage data. The good news is that version 1.2 of the sonar C# plugins brings a workaround. You can activate the "gallio safe mode" and the sonar gallio the SonarQubeGallio plugin will merge the coverage data. See the gallio config Gallio configuration page for more details on this.
0% code coverage using reuse reports mode
Thanks a lot to Stéphane Lopes for the tip.
Gallio execution fails on a Windows 64bits system
If in the logs you get something such as:
[INFO] [23:30:05.643] A fatal exception occurred while running tests. Possible causes include invalid test runner parameters and stack overflows. [INFO] [23:30:05.727] Gallio.Model.ModelException: An exception occurred while invoking a test driver. ---> Gallio.Model.ModelException: Gallio.Model.ModelException: Could not load test assembly from 'C:\whatever\MyTestAssembly.Test.dll'. ---> System.BadImageFormatException: Could not load file...
that might be because some of your assemblies have been compiled with a x86 profile (32 bits) while Gallio is configured to run in an "Any CPU" mode, hence 64bits on your system.
This problem might be solved using corflags tool to force Gallio to run in a 32 bits mode as shown below:
corFlags.exe Gallio.Echo.exe /32BIT+ /Force
Some tests fail unexpectedly using a legacy .net2 library
The java process performing the code analysis might need more RAM. Use the "-Xmx" option to specify the amount of memory that can be use. See the Sonar SonarQube Runner documentation for more details
This rule works at class level. If you are working on a windows form or asp.net project, you may have many partial classes. The code generated in the "designer" parts may contain many "visible fields" whereas the real code that matters does not contain any defects. In order to avoid these false positives, you have two options:
- disable Disable this rule. Probably not the best option.
- Use the switch off violation Switch Off Violations plugin to disable the rule only on "view" related components.
On an asp.net project you may configure the switch off violation Switch Off violations plugin as follow: