I'm tring to run analysis on SonarQube, using an FxCop custom Rule.
In SonarQube 4.5.7 I add the rule to the set of rules, I activate it and then run the analysis.
To run the analysis I use the sequence of following commands:
1) MSBuild.SonarQube.Runner.exe begin /k:my.project.C-Sharp-ConsoleApp /n:C-Sharp-ConsoleApp /v:1.1
2) "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild" /T:Rebuild
3) MSBuild.SonarQube.Runner.exe end
I see that the rule is executed, because when I run the second command I read the following part of log:
...
(RunCodeAnalysis target) ->
MSBUILD : warning CR1000: MyRules : Field 'CSharpSortNames.m_variabile' is not in Hungarian notation. Field name should be prefixed with 's'. [C:\Users\Alessandro\Documents\Visual Studio 2015\Projects\C-Sharp-ConsoleApp\C-Sharp-ConsoleApp\C-Sharp-ConsoleApp.csproj]
My custom rule checkID is CR1000, and after the third command, I see that an error of this rule is founded, but the web app doesn't let me see where. For all other errors the web app let me see the precise line where is the error by a link to the .cs file. For my rule it doesn't.
Anyone can help me about this?
Further problem is in SonarQube 5.4 the same rule is activated but web app does not show the error.
The root cause here is that FxCop uses information from the PDB file for providing location information. However, the PDB only contains information that would be useful for debugging scenarios, which means that FxCop rule violations that are associated with non-executable code (e.g.: field declarations or interface definitions) will not have location information available. (FWIW, there is an open SonarQube issue for addressing this, but it would be non-trivial to accomplish unless SonarQube were to directly examine the source files to attempt to locate the field declaration. I rather suspect they might not bother given that it simpler to address via a Roslyn analyzer.)
Further problem is in SonarQube 5.4 the same rule is activated but web
app does not show the error.
That's because older versions of the C# plugin for SonarQube completely ignored FxCop violations without location information. This was addressed in version 5.2 of the plugin, which only became in early May 2016 (and is presumably what you used when you installed SonarQube 5.5). It is compatible with version 5.4 of SonarQube, so you should be able to use it with your older installs if you like.
Related
Very common problem for many users, that SonarQube Code Analysis fails with an error:
[10:06:05]No ProjectInfo.xml files were found. Possible causes:
[10:06:05]1. The project has not been built - the end step was called right
after the begin step, without a build step in between
[10:06:05]2. An unsupported version of MSBuild has been used to build the
project. Currently MSBuild 12.0 upwards are supported
[10:06:05]3. The build step has been launched from a different working folder
[10:06:05]Post-processing failed. Exit code: 1
[10:06:05]Process exited with code 1
A lot of references say that fix is to use full path for MSBuild.exe, but yes, I use full path, but also I use MSBuild 15.0 version with newest C# version, older MSBuild just fails for new C# features in code.
However I can't get rid of this error and I have no idea what can be done about it, so maybe any of you guys have already met this problem and could help me?
EDITED
I am pretty sure that none of these steps should be the reason for the fail, the second one only the closest one, because my build steps are
Team City build steps look like the following.
Step XX:
cd %projectDirectory%
"C:\sonarqube-5.3\bin\MSBuild.SonarQube.Runner\MSBuild.SonarQube.Runner.exe" begin ... params
"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild.exe" "MyProject.sln" /t:Clean;Rebuild
Step XY:
...
Step XZ: (the last)
cd %projectDirectory%
"C:\sonarqube-5.3\bin\MSBuild.SonarQube.Runner\MSBuild.SonarQube.Runner.exe" end
For me it looks very simple and easy to understand, but still I got that error and I have no idea why, the error is thrown in the last step (XZ).
You need to upgrade to a newer version of the Scanner for MSBuild. I'd suggest upgrading to the newest available version (v4.2 at the time of writing).
The scanner copies a targets file under the following location for each supported version of MBuild: %localappdata%\Microsoft\MSBuild[MSBuild version]\Microsoft.Common.targets\ImportBefore.
From the look of the log output you are using an version of the Scanner for MSBuild that pre-dates the release of MSBuild 15, so the file won't be copied to the MSBuild15-specific location. This will lead to the "no ProjectInfo.xml files were found" state.
It would be better if the warning message in the scanner log explicitly listed the range of MSBuild versions that were supported e.g. "This version of the Scanner supports MSBuild v12.0 to v14.0". I've created issue #502 to track this.
Following on from this tutorial from MS, I have created an analyzer for Roslyn.
According to the page, you can mark the rule as DiagnosticSeverity.Error, and this will cause the build to break:
In the line declaring the Rule field, you can also update the severity of the diagnostics you’ll be producing to be errors rather than warnings. If the regex string doesn’t parse, the Match method will definitely throw an exception at run time, and you should block the build as you would for a C# compiler error. Change the rule’s severity to DiagnosticSeverity.Error:
internal static DiagnosticDescriptor Rule =
new DiagnosticDescriptor(DiagnosticId, Title, MessageFormat,
Category, DiagnosticSeverity.Error, isEnabledByDefault: true, description: Description);
In my code, I have created the rule more or less as detailed here:
private static readonly DiagnosticDescriptor Rule =
new DiagnosticDescriptor(DiagnosticId, Title, MessageFormat, Category,
DiagnosticSeverity.Error, true, helpLinkUri: HelpUrl);
This rule works fine. It throws up the red lines, it displays the message in the errors list. However, the build succeeds, and I am able to successfully run the application.
NB: I've created this rule to capture Thread.Sleep for this example.
Is there additional setup required to ensure a rule breaks the build?
This is a feature of Analyzers running from a VSIX file.
If the IDE-installed rules ran as part of the in-IDE build, it would result in IDE builds and command line builds having potentially very different outputs. For example, a user with code-cracker installed as a VSIX could end up filing a bug report that an open source project does not build due to an analyzer error (or perhaps a warning when the project uses /warnaserror). They would be forced to either uninstall the analyzer extension or modify the rule set used by the project to disable some rule that only exists on one developer's machine.
In contrast, rules that are installed via NuGet become part of the project and part of the build. They run the same way across developer machines, and they run the same way in-IDE, on the command line, and in automated build environments.
Source: IDE rules don't fail builds
In order to make the build fail for the rules, you need to add the analyzer as a nuget package to the project. This will ensure that failures will cause the build to fail as expected.
I've got a solution containing two MVC 5 web applications with associated class libraries and the code analysis settings are causing the build to hang. If I try to interact with the UI during this time I get the "VS is busy" bubble. Leaving the build to complete overnight doesn't work either.
To troubleshoot this I turned off code analysis on all projects and the project builds just fine [0]. So I enabled the "Microsoft All Rules" on one of the MVC projects and the build process doesn't complete.
"Microsoft Managed Minimum Rules" builds but what I'd now like is that there's some kind of structured way of going through the rulesets, where the next one I try is a superset of the last successful one. Does such a hierarchy exist, and if so, is there a canonical reference for it?
Once I get to that level then I can start to isolate individual rules, perhaps by increasing the verbosity of the build output...
[0]
This statement should not be interpreted as "Building without code analysis is perfectly okay"
A general hierarchy is exposed via the Include elements in the .ruleset files located under the Visual Studio install directory (e.g.: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets for a typical VS 2015 installation). Broadly, it looks something like this (with "All Rules" not actually depending on any of the others):
All Rules
Extended Correctness Rules
Basic Correctness Rules
Minimum Recommended Rules
Extended Design Guideline Rules
Basic Design Guideline Rules
Minimum Recommended Rules (same as above)
Globalization Rules
Security Rules
It's also worth noting that this isn't a clean hierarchy without overlaps. For example, rules included in the "Globalization" and "Security" rulesets are also included in some of the others (including the "Minimum" set).
To inherit from a ruleset file, you can include it with:
<Include Path="MyOther.ruleset" Action="Default" />
Then you can override the action for specific rules.
I created a project in VS 2010. I want to convert it into VS 2013. When I build it, there is an error:
CA0053 Error Running Code Analysis CA0053 : Unable to load rule assembly 'c:\program files\microsoft visual studio 10.0\team tools\static analysis tools\fxcop\rules\globalizationrules.dll': Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
I disabled the "Enable Code Analysis in Build" and run, then it doesn't give me an error.
What is the importance of Enabling Code Analysis?
What will happen if disable the Code Analysis?
The CA0053 error you get is a known issue when converting from VS 2010 to VS 2012/13. I have listed up how to fix just that issue here: http://geekswithblogs.net/terje/archive/2012/08/18/how-to-fix-the-ca0053-error-in-code-analysis-in.aspx
The underlying cause is that your project is bound to the specific version, and should be version independent, caused by using an absolute path to the VS 2010 binaries.
You can change that in the project file, as described in the post.
If you want to do it manually, the basic steps are:
Open the project file (.csproj) in a text editor
Locate the lines for <CodeAnalysisRuleDirectories> and <CodeAnalysisRuleSetDirectories>
Replace them with the lines
shown here
<CodeAnalysisRuleDirectories>$(DevEnvDir)\..\..\Team Tools\Static Analysis Tools\FxCop\Rules</CodeAnalysisRuleDirectories>
and
<CodeAnalysisRuleSetDirectories>$(DevEnvDir)\..\..\Team Tools\Static Analysis Tools\Rule Sets</CodeAnalysisRuleSetDirectories>
As noted in the blog post, in many cases it seems you also can just delete the lines. You can try that first, if that doesn't work, do step 3 above.
What is the importance of Enabling Code Analysis?
So that your code gets analyzed.
What will happen if disable the Code Analysis?
Your code won't be analyzed.
Code analysis gives you hints about your code. It is a style and security check for the code you write.
See for more info MSDN: Code Analysis for Managed Code Overview and MSDN: Analyzing Managed Code Quality by Using Code Analysis.
It was a long WTF moment and I could not find any information on the issue, so I decided I put it here.
Setup: Windows 7 x86_64, sonarqube-4.3, sonar-runner-2.4, jre 1.7.0_55-b14
I followed quick start guide to configure Sonar.
I copied sonar-project.properties from a sample to my solution, put it in the directory with .sln, and made necessary adjustments:
sonar.projectKey=org.whatever.project
sonar.projectName=Project
sonar.projectVersion=2.0
sonar.sourceEncoding=UTF-8
sonar.sources=.
sonar.visualstudio.enable=true
Problem: Analysis ran without any exceptions but only C# files were analyzed.
Long story short, following line in config was causing the issue:
sonar.sources=.
After moving sonar-project.properties one level up and changing it accordingly, the problem was resolved.
sonar.sources=src
I think it actually relates to the usage of the Visual Studio Bootstrapper. Can you try the same without it?
Here is what happens: The Visual Studio bootstrapper reads all the <Compile> tags from the *.csproj files to determine which files must be imported. Javascript files are not referenced by <Compile> (as they do not need to be compiled), and will therefore not be imported in SonarQube.
See this related Jira ticket: https://jira.codehaus.org/browse/SONARVS-27