Version 3.0 of the C# plugin is an almost complete rewrite of what was previously known as the ".NET ecosystem". This was required in order to support SonarQube 4.2, its multi-language feature, and to be able to offer a better user experience.
Despite the magnitude and scope of the changes, we tried to reduce the migration effort to a minimum.
What features have been dropped?
- Execution of tests (through Gallio) - only the import of existing code coverage reports is now supported
- Architectural rules (NDeps) - no replacement
- Gendarme, an abandoned rule engine with no release for over 3 years, support has been dropped
- Path patterns such as "$(SolutionDir)", "$(ProjectName)", etc. are no longer supported. These properties were only required for advanced use cases, and shouldn't required now that the plugins are easier to use. The Analysis Bootstrapper for Visual Studio Projects plugin will feed the right values for most of the properties.
What features haven't yet been reimplemented?
- The analysis of ASP.NET projects is not yet supported.
- The import of test execution results is not yet supported. (SONARPLUGINS-3678, SONARPLUGINS-3691)
- The import of JetBrains' dotCover code coverage reports is not yet supported. (SONARPLUGINS-3679)
- FxCop and ReSharper custom rules (SONARPLUGINS-3692, SONARPLUGINS-3693, SONARPLUGINS-3697)
Do not use the update center
The update center does not yet support the removal of plugins from ecosystems.
You will need to remove all previously installed .NET plugins before installing the new ones.
New plugin organization
There no longer is any abstract .NET or C# "core" plugin. Instead, .NET is now supported by 4 plugins:
- StyleCop - Adds the support of StyleCop. Requires C# to be installed
- R# / ReSharper - Adds the support of R#. Requires either C# or VB.NET to be installed
- Analysis Bootstrapper for Visual Studio Projects - Reduces the manual configuration required to launch a SonarQube analysis by extracting information directly from Visual Studio solution and project files
Before the update, use the "safe" key strategy.
Before this rewrite, the use of
sonar.dotnet.key.generation.strategy=safe was optional. After this rewrite, it is automatic. If you were already using the safe strategy, you have nothing to do, and can safely skip the rest of this section. If you were not, please read on.
|This "sonar.visualstudio.projectKeyStrategy" should not be used in production, and is provided only as a way to migrate to the 3.0 version of the plugin. It can be removed at any point of time in the future.|
FxCop issue mapping
FxCop reports its issues on bytecode.
With the new plugins, any analysis that includes FxCop rules will fail if the *.pdb file corresponding to the assembly is not found.
Support of Team Foundation Server builds
TFS builds, which output assemblies of all projects to a common folder, are supported by the Analysis Bootstrapper for Visual Studio Projects using the "sonar.visualstudio.outputPath" property.
Excluding generated code
"sonar.dotnet.excludeGeneratedCode" was previously supported to ignore generated code.
The same behavior is now achieved by setting the standard exclusions property "sonar.exclusions" to "**/Reference.cs", "**/*.designer.cs", "**/*.Designer.cs" and "**/*.g.cs".
The lines / lines of code metric increased with the new plugin
The old .NET ecosystem has issues with supporting generic types. Those issues have been fixed. Therefore analysis with the new plugins can result in higher values for the lines and lines of code metrics, if generics were heavily used in the project. Additionally, the files metric also changed slightly.
Because of the increased accuracy of these basic metrics, you may notice a ripple effect through the other metrics that are derived using these numbers.
The issues metric decreased with the new plugin
The old .NET ecosystem allowed rules engines such as FxCop to report issues on the project level, without attaching them to specific files.
The new behavior of the plugin is to not import such issues. The drilldown will now always work properly, but a decrease is the issue metric is to be expected.
Old versus new properties
The properties from the old .NET ecosystem that still apply are still supported in order to reduce the migration cost.