Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

General Questions

What is the difference between the Sonar .NET Plugins (up to version 0.6) and the Sonar C# Plugins Ecosystem (from version 1.0)?

Historically, the support for the C# language was created under the ".NET Plugins" name, from version 0.1 to latest 0.6 released in June 2011.
In the mean time, a complete rewrite of those plugins started in late 2010 in order to make C# a first-class language in Sonar. This not only involved upgrading the plugins to the latest APIs and Sonar development best-practices, but also making evolutions on the core of the Sonar platform itself to support new needs that the Java world had not brought before.
The set of plugins was rebranded "C# Plugins Ecosystem" to highlight the enhanced support of the C# language (C# being just one of several languages running on top of the .NET platform).

The main differences between those 2 sets of Sonar plugins are:

  • Home-made C# parser: no need to install SourceMonitor anymore, all the metrics are computed by the brand-new Sonar C# Core plugin. This opens lots of possibilities for the future, like being able to create our own C# rules.
  • Better support of copy-paste detection, based on the new C# parser
  • Maven is no more required for execution: assuming that you're solution has been compiled, you can run a Sonar analysis just with the Sonar Runner
  • Java 6 is no more required for execution: the plugins run fine on a Java 5 VM
  • Native support of Sonar way to handle multi-module: a .NET solution that contains C# projects will be considered like a standard root project with modules in Sonar. Each tool such as FxCop, StyleCop or Mono Gendarme will be run on each of these Visual Studio projects. With the dotnet plugin version 0.6, except for Gendarme, tools were launched only once for a whole Visual Studio solution.

Unlike the former dotnet plugins, the Sonar C# plugins do not provide features such as compilation or packaging. These plugins are focused on their job : code quality analysis. That being said for compilation/packaging. You can still use whatever solution best feet your needs such as MsBuild scripts, Nant scripts or the maven-dotnet-plugin if you are familiar with maven.

To remember

Icon

The C# Plugins Ecosystem is not just an evolution of the .NET plugins, it is a complete rewrite and thus introduces many changes. If you were a .NET plugins user before, we advice you to read the notes below about the migration process.

How should I migrate from the .NET Plugins 0.6 to the new C# Plugins Ecosystem 1.0, and what will change?

We tried to ensure backward compatibility at configuration level as much as possible, so the migration process should be pretty simple: remove the .NET plugins and add the new C# ones.
If you where using the dotnet plugins, your maven configuration files do not need to change at all and can be reused with the new C# plugin. There is just a tiny exception to the previous sentence, if you use NCover for test coverage. See below for details...

Below a list of things to consider when migrating :

  1. Gallio is not embedded anymore. Dotnet plugins version 0.6 comes with an embedded version of Gallio. This is not the case of the C# Gallio plugin which needs Gallio installed on the boxes where the analysis will be performed.
  2. NCover is not activated the same way using property "useNCover". Instead you need to set property "sonar.gallio.coverage.tool" to "NCover".

So far we have seen only those two points. We'll enhance this section as we get feedback from users.

What will changes once the migration is done?

Icon

Size & complexity metrics are now computed by the C# Core Plugin, so they will definitely change (results will better reflect the reality, hopefully). As a consequence, this will also have impacts on some other metrics, like the rule compliance for instance.

Do I really need Java in order to analyse my C# projects ?

Actually you do not !
The analysis can be triggered either by the Sonar Runner or by maven. Both are Java programs so what is the trick? The Sonar Runner works fine with IKVM. IKVM is a very nice open source project which implements java in .net. If you want to try it with the Sonar Runner, you just need to edit the script sonar-runner.bat and replace the call to java by a call to IKVM:

In place of java, a .net process will be used. IKVM will recompiled on the fly the java jars used for the analysis to .net dll files. The recompilation will slow down significantly the analysis. IKVM could be used to transform jar files to dll files prior to any execution (using ikvmc). The problem is that the sonar runner downloads plugins jar files at the beginning of the analysis from the target sonar server instance. Hence we cannot pre compiled all the jars files needed to run an analysis without changing the way the runner works. 
Right now it is not very useful to use IKVM with the sonar runner. However, this looks very promising for a future Visual Studio integration (wink)

How can I exclude a project from the analysis of a .NET solution?

You can do so using the standard "sonar.skippedModules" property (see Analysis Parameters page for Sonar properties): it is a comma-separated list of project names. The names that you must use here are the identifiers that you can find in the .SLN file: the identifier is the first string you can find right after the equals sign on a project definition. 

For instance, on the following SLN file excerpt, you would use "FooProject":

Sonar C# Parser

What are the current limitations?

Currently, the SonarSource C# parser has the following limitations:

Rules

How can I use FxCop with Visual Studio Static Analysis rules in sonar?

Check out this page, where everything is explained.

Tests and code coverage

How can I run Gallio and PartCover on a 64-bits Windows?

Gallio and PartCover work perfectly out-of-the-box on x86 Windows, but not on 64-bits versions of this OS. To make them work correctly, here's what you have to do:

  1. Download the latest Gallio x64 installer (http://www.gallio.org/Downloads.aspx) and install it in a folder not under "Program Files"
  2. Download the latest PartCover installer (https://github.com/sawilde/partcover.net4, click on Downloads) and install it in a folder not under "Program Files"
  3. Run "corflags.exe" on Gallio and PartCover executables:

(Source: http://www.planetgeek.ch/2009/10/15/get-partcover-running-on-x64-windows/)


How can I run integration tests ?

Icon

Available since version 1.3 of the C# plugins

Integration testing is activated using property sonar.gallio.it.mode :

Integration tests must be part of the analysed solution. They can either be located in dedicated projects or located in regular test projects, next to unit tests.
If there are located in dedicated projects, theses projects need to be specified using property sonar.dotnet.visualstudio.itProjectPattern. Below an example :

If integration tests are next to unit tests, in the same projects, you need to specify to sonar which ones are unit tests and which ones are integration tests. Gallio filters comes to the rescue : 

With the preceding configuration fragment, all test cases annotated "unit" (i.e. [Category("unit")]) are considered to be unit test cases whereas test cases annotated "selenium" (i.e. [Category("selenium")]) are considered to be integration test cases.

Compatibility with other plugins

SCM Activity plugin

The C# Plugins Ecosystem is compatible with the SCM Activity plugin, provided that you have specified the "sonar.scm.url" property in your POM or "sonar-project.properties" file. For instance:

Other plugins

Those plugins have been reported as compatible with the C# Plugins Ecosystem:

  • Build stability
  • Timeline
  • Radiator
  • Sqale
  • Views

Integration of Sonar with Other Environments

How can I integrate Sonar in my existing TFS Build environment processes?

Most people want to add Sonar as an additional step in existing processes, which usually brings a lot of troubles because those processes manipulate the generated artifacts (assemblies) - whereas Sonar C# Plugins rely best on information found in the source files (mostly CSPROJ config files).

Generally speaking, it's best / easier to set up a separate "continuous inspection" process that just:

  1. compiles the solution
  2. runs a Sonar analysis

, in order to keep the Sonar-related configuration as simple as possible.

You can read this thread to see how this has been achieved by C# plugin users.

  • No labels