Support for SonarQube analysis of projects in the new MSBuild v15 format (of which .NET Core projects are the best-known example) has been one of the features most requested by the Microsoft community. We are pleased to announce this is now supported in the latest releases of the SonarQube Scanner for MSBuild (v4.0) and Sonarlint for Visual Studio (v3.8). In addition, MSBuild v15 projects that produce output for multiple platforms are supported, and we have started adding support for analysis on non-Windows machines.
Previously, SonarLint did not recognise the project type used for C# and Visual Basic projects in the new MSBuild 15 format, and so would not update the project with the required references to the analyzers or the ruleset that was generated to match the Quality Profile on the SonarQube server.
SonarLint for Visual Studio 2017 now supports both the old-style MSBuild project format (i.e. the analyzer NuGet package is referenced in the packages.config file and the analyzer assemblies are referenced in the project file) and the new format (i.e. the analyzer NuGet package is referenced directly in the project file). Solutions can contain projects in both formats.
As Microsoft does not support the .xproj tooling in VS2015 and is actively encouraging developers to migrate to the tooling that is supported in VS2017, we decided not to add support for .xproj to SonarLint for Visual Studio 2015. However, we are continuing to release SonarLint for VS2015 at the same time as SonarLint for VS2017, so users of VS2015 can benefit from the new rules and bug fixes in the SonarC# and SonarVB code analyzers.
The new MSBuild project format makes it easy to have a single project that targets multiple frameworks (e.g. netstandard1.3;netstandard1.4;net462). Building the project will produce multiple assemblies, one per target framework. Such projects usually contain #if TARGET_PLATFORM conditional compilation directives in the code to handle platform-specific behaviour. This means that each assembly can have different code analysis issues and different metrics (e.g. lines of code and cognitive complexity).
This is not a problem for the developer when working in the IDE; the developer chooses which platform is currently “active” and Visual Studio will only analyze the code associated with that platform.
However, it does make a difference when sending the analysis results to SonarQube. The SonarQube Scanner for MSBuild takes a pragmatic approach - it analyses all of the assemblies and combines the issues so that issues that occur in more than one assembly are only reported once. The story with code metrics is slightly more complicated. For example, it isn’t obvious how to calculate or report the complexity of a method that contains conditional compilation. In this version, we take the simple approach of uploading only one set of the metrics. We might change the behaviour in the future based on user feedback (which can be provided via the SonarQube Google group).
Note: the version of the project metrics to upload is chosen deterministically by ordering the assemblies by Configuration-Platform-TargetFramework and then picking the first one (see here for the actual code).
The release of .NET Standard 2.0 by Microsoft simplified the job of porting .NET applications to non-Windows platforms. That made it much easier for us to port the SonarC# and SonarVB code analyzers and SonarQube Scanner for MSBuild so that it is now possible to run an analysis from the command line on Linux and iOS. Have a look at the online documentation for detailed instructions on how to set this up.
Currently it is necessary to have Mono v5.4 installed for the Scanner for MSBuild to run on non-Windows platforms. This requirement might be dropped in the future if we can remove some of the existing dependencies from the scanner.
The current version (v3) of the SonarQube extension for VSTS will only work on Windows build agents as it is written in PowerShell. We are currently re-writing the extension in NodeJS to make it possible to use the extension on non-Windows build agents as well.
The re-write of the extension is part of a larger piece of work that will simplify and consolidate the configuration of SonarQube and SonarCloud analysis for other types of projects. Currently, the SonarQube VSTS extension only handles .NET projects, with the analysis of Maven and Gradle projects being handled separately in the Java build task. The next version of the VSTS extension will provide a single set of tasks that will be used across all project types, as well as being runnable on non-Windows build agents. Watch this space…
As ever, we are interested in your feedback which can be provided using the SonarQube Google group. Alternatively, you can track issues and the current work in progress using the following links: SonarLint for VS, Scanner for MSBuild, SonarC# and SonarVB code analyzers.