I am trying to setup SonarQube to report on our C# projects. I have created a new Quality Profile in SQ which only include the Code Analysis rules (225 in total). I have made sure that these rules are in sync with the projects in source in Visual Studio.
When SonarQube analysis is run, different results are reported. Visual Studio tends to pick up more than the SonarQube runner.
For example, here are 3 results from SonarQube about rule CA1704:
and for the same solution in VS, there are many more:
The 3 that I have highlighted are the 3 that SonarQube is picking up.
This is the same for a number of different rules. I want SQ and VS to report the same results. I run analysis on TFS build (vNext), can I simply pass the results from the build to SonarQube? I mean, if I don't have to run it twice then great.
Do I need to modify the SonarQube rules themselves? Has anyone experienced this problem before?
UPDATE
I have enable verbose logging on the sonar publish and I have found that it is skipping some issues found:
2016-01-08T14:33:53.5086817Z 14:33:53.430 DEBUG - Skipping the FxCop issue at line 10 which has no associated file.
2016-01-08T14:33:53.5243155Z 14:33:53.430 DEBUG - Skipping the FxCop issue at line 19 which has no associated file.
There are lots of these for every project in my solution and the gap matches exactly, e.g. in the above case, VS reports 47 issues but SonarQube reports 45. I cannot yet find a correlation and Google doesn't have much info on it. This is going to be a big problem as one of my solutions has 18.5k issues but SonarQube is only reporting 13k.
Are the CA1704 violations that aren't showing up in SonarQube for classes or for members that are declared as fields, as opposed to properties? If so, you've run into one of the more "interesting" behaviours of the FxCop plug-in for SonarQube, which is that it ignores any violations that do not include a file and line number (see the relevant source file at https://github.com/SonarSource/sonar-fxcop-library/blob/master/src/main/java/org/sonar/plugins/fxcop/FxCopSensor.java, of which current version is c518065 for the details if you're interested).
Line numbers in FxCop reports are taken from the PDB for the target assembly. However, the PDB only contains lines for executable code, so violations that aren't associated with executable lines of code (or at least with a method that FxCop can tie to its first line) won't have a file name or line number in the FxCop report. These will all end up getting ignored by SonarQube.
If you're dependent on SonarQube reporting of your FxCop results, you may wish to consider submitting a bug report.
Related
I have integrated SonarQube via Jenkins for various applications. We have separate visual studio solutions for different applications. Somehow SonarQube combines analysis report for various applications under a single report.
How can I generate separate report for each application? I have the following properties to run Sonar analysis via Jenkins.
sonar.projectKey=SONAR_TEST
sonar.projectName=SONAR_TEST
sonar.projectVersion=1.0
sonar.sources=C:/$Application_Name (Note: $Application_Name is root folder name of various applications)
sonar.host.url=https://server_name:8080/sonar/
The reason it is aggregating the reports is because you are telling it to.
SonarQube results are displayed by "Project", based on projectKey. You appear to be setting the same fixed projectKey(and projectName) for every job.
sonar.projectKey=SONAR_TEST
sonar.projectName=SONAR_TEST
sonar.sources=C:/$Application_Name
Change the projectKey(and projectName) to align with the "$Application_Name" (and give the projectName a user friendly name if you like). Omitting the projectName defaults to the projectKey.
By default, if a maven project, the project is the GroupId:ArtifactID. Other types do not have a default key, but you can generally use similar logic to align.
You can enter this information in a sonar-project.properties file inside your root folder (ie: $Application_Name/sonar-project.properties)
Note: Key cannot have spaces, Name can.
I'm having some trouble with performing analysis on a project, and I'm not quite sure how to work around it.
I am working with an engineer to get one of their applications into Sonar. It's a large solution with many projects as part of it. When I performed a build and Sonar analysis as part of a TFS build, I get the following error:
##[error]No analysable projects were found but some duplicate project IDs were found. Possible cause: you are building multiple configurations (e.g. DEBUG|x86 and RELEASE|x64) at the same time, which is not supported by the SonarQube integration. Please build and analyse each configuration individually.
I took a look at the configuration management in their solution properties and found that there were some different configurations per project. Most were set up for Debug|Any CPU, but there were a couple set up for Debug|x86 and Dev|Any CPU.
I tried building just one particular project by using the MSBuild argument /t:, but still ran into the same thing. I've also tried specifying the configuration and platform as MSBuild arguments, but no luck. Is there any possible way to do the analysis without having to change the configuration of the projects directly?
Any help would be appreciated! Let me know if you need any additional information.
According to this website, SanarQube has no plans at the moment to support multiple configurations in the short term.
You would need to setup a separate single configuration build for the SonarQube analysis.
We have FxCop analysis being run by Nant/Jenkins. A SonarQube C# analysis is then triggered, and executed successfully.
We'd like to reuse fxcop.xml result file from Jenkins for Sonar's analysis.
We tried this configuration with no luck:
sonar.fxcop.mode=reuseReport
sonar.fxcop.reportsPaths=fxcop.xml
SonarQube is asking for path to FxCopCmd.exe. If specified, Sonar is running FxCop analysis one more time. We don't want that.
According to this thread sonar.fxcop.mode is no longer supported.
Quoted from the thread:
You can skip the execution of FxCop on a specific project by using
another Quality Profile for it, that does not contain any FxCop rule.
Indeed, it is important for the evolution of a project's technical
debt to be trackable over time. Changes in the rules that are applied
during the analysis has an obvious impact on the technical debt, and
therefore should be tracked.
The "sonar.fxcop.mode" property did not allow that, and was therefore
removed. For example, with the reuseReports mode, you could launch
just 1 or 2 rules, whereas in SonarQube all FxCop rules are enabled.
Skipping the FxCop analysis fully when all FxCop rules are enabled in
SonarQube is obviously deceiving.
The reuseReports mode should not be required, as SonarQube is able to
drive FxCop's execution.
I guess FxCop should be started from Sonarqube direct.
I am using Visual Studio 2013 and Team Foundation Server 2013. I have these, as well as the Build Controller/Agent, running on my personal computer, called "FUSROHDAH".
My goal is to take a build generated by the TFS Build Agent and open it for debugging in Visual Studio, and have it leverage the source indexed PDB to access the source code from the TFS source control system so that I can step through the code. I have studied several informative articles about PDB's and source indexing, including:
Ed Squared's article on Source Server and Symbol Server Support in TFS 2010
John Robbins' article about PDB files
I also watched John Robbins' very excellent video on WintellectNOW which discussed a lot of the nuances of setting up the symbol server, source indexing.
However, despite several days of hair pulling, I haven't been able to get this working yet.
I've set up TFS for continuous integration. Here are my settings:
In Build Definition->Build Defaults, I have set Staging Location to "Copy build output to the following drop folder (UNC path, such as \server\share)":
\\fusrohdah\builds (this equates to c:\builds on my machine)
Build Definition->Process Template Settings:
Path to Publish Symbols: \\fusrohdah\symbols\ (this equates to c:\symbols on my machine)
I notice that the Default Process Template in TFS 2013 looks different from the articles discussing TFS 2010. In Ed Squared's article, there is an option for "Index Sources". In TFS 2013, this setting is gone, and in the instruction text, it says "Specify the path to the symbol store share. When this value is set, source indexing is a part of the build." So I assume that I have source indexing running on my builds, by simply specifying this location.
So I take a simple console application HelloWorld and I perform a series of changes and check-ins. I observe the builds are published to the builds folder as I would expect, with an EXE and PDB file side by side.
So I want to take an older build and debug it in Visual Studio, and step through source code obtained from the TFS source indexing. I open the EXE in Visual Studio and hit F11 to launch the console application and begin stepping into the code in the Main() procedure. But, when this happens, I get this message:
--------------------------- Microsoft Visual Studio
--------------------------- Source file: C:\builds\2\LocalTestProject\HelloWorld\src\HelloWorld\HelloWorld\Program.cs
Module: C:\builds\HelloWorld\HelloWorld_20140722.6\HelloWorld.exe
Process: [6016] HelloWorld.exe
The source file is different from when the module was built. Would you
like the debugger to use it anyway?
This seems to be the crux of my problem. My understanding is that when Visual Studio reads my PDB file, it should execute TF.exe to obtain the correct version of the source code from TFS, and it seems to be failing to do this. I used PDBStr.exe to look at the PDB file published by the build, and nothing seems amiss:
c:\builds\HelloWorld\HelloWorld_20140722.6>pdbstr -r -p:helloworld.pdb -s:srcsrv
SRCSRV: ini ------------------------------------------------
VERSION=3
INDEXVERSION=2
VERCTRL=Team Foundation Server
DATETIME=Tue Jul 22 23:04:51 2014
INDEXER=TFSTB
SRCSRV: variables ------------------------------------------
TFS_EXTRACT_CMD=tf.exe view /version:%var4% /noprompt "$%var3%" /server:%fnvar%(
%var2%) /console >%srcsrvtrg%
TFS_EXTRACT_TARGET=%targ%\%var2%%fnbksl%(%var3%)\%var4%\%fnfile%(%var5%)
SRCSRVVERCTRL=tfs
SRCSRVERRDESC=access
SRCSRVERRVAR=var2
VSTFSSERVER=http://fusrohdah:8080/tfs/DefaultCollection
SRCSRVTRG=%TFS_extract_target%
SRCSRVCMD=%TFS_extract_cmd%
SRCSRV: source files ---------------------------------------
C:\Builds\2\LocalTestProject\HelloWorld\src\HelloWorld\HelloWorld\Program.cs*VST
FSSERVER*/LocalTestProject/HelloWorld/HelloWorld/Program.cs*18*Program.cs
SRCSRV: end ------------------------------------------------
I observe in the Output window that Visual Studio thinks it has successfully loaded the symbols when I'm debugging my EXE. I do not see a message indicating that it ran TF.exe, however, so I believe it is failing to run this to obtain the source.
I did verify in Visual Studio that I have "Enable Just My Code" UNCHECKED, and "Enable Source Server Support" CHECKED, along with "Print Source Server diagnostic messages to the Output Window".
Question: how do I know if Visual Studio is attempting to run TF.exe to obtain source code from TFS like I would expect?
Aside from that, I'm not sure if my problem is with the build configuration, symbol server/source server configuration, or my approach to attempting to debug using the aforementioned pieces. I will pledge fealty to the wizard who can illuminate my path for me!
Have you tried removing the build server working directories before debugging ? If a debugger can find the files denoted in SRCSRV on disk it will take precedence over getting them with tf.exe (even if they are the wrong version match). Only if it can't find the files on disk or in cache, it will try reference the source server. Because you are performing this on the buildserver, the locations denote a later version of the sources.
We are using only FxCop and StyleCop rules in Jenkins and Sonar.
But we are getting more no. of Violations on Sonar Dashboard then in Jenkins.
Jenkins in using 318 rules (FxCop & Stylecop Combined) whereas Sonar is using only 130 rules (FxCop & Stylecop Combined).
But still we get more no. of Violations on Sonar Dashboard then on Jenkins.
Can anyone tell me why this is happening?
And Jenkins shows result of FxCop and StyleCop seperately, whereas Sonar merge result of FxCop and StyleCop and display them. Does any one know how can we seprate the result ?
There can be several explanations why you get more violations in Sonar:
the FxCop and StyleCop rules are not configured with the same parameters (threshold, ...) between Sonar and Jenkins. This is the first thing you should do actually.
maybe you also have Gendarme rules activated in your quality profile on Sonar? (this is the case if you're using the default "Sonar way" profile)
you may also have lots of other Sonar violations (which don't come from external tools like FxCop), ranging from detected duplications to design issues.
And to answer your last question, there's currently no way in Sonar UI to seperate violations based on the tool that generates them. The most important for Sonar users is to get the whole list of violations, whatever the tool that generates them is.