TL;DR overview
- SonarQube supports analysis of .NET Core and ASP.NET Core projects through the SonarScanner for .NET, enabling automated code quality and security scanning in both local development and CI/CD pipeline environments.
- The scanner integrates with MSBuild and .NET CLI build workflows, automatically collecting the compiler information needed for accurate analysis without additional manual configuration for most project types.
- C# analysis in SonarQube detects bugs, code smells, and security vulnerabilities specific to .NET applications, including LINQ misuse, null reference risks, and insecure deserialization patterns.
- Connected Mode with SonarQube for IDE in Visual Studio allows .NET developers to see the same analysis results in the IDE that CI/CD pipelines enforce, maintaining consistency between local and server-side quality standards.
Support for SonarQube Server 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 Server Scanner for MSBuild (v4.0) and SonarQube for IDE: 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.
SonarQube for IDE: Visual Studio 2017 Connected Mode now supports .NET Core projects
Previously, SonarQube for IDE 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.
SonarQube for IDE: 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.
What about .NET Core projects in Visual Studio 2015?
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 SonarQube for IDE: Visual Studio 2015. However, we are continuing to release SonarQube for IDE for VS2015 at the same time as SonarQube for IDE for VS2017, so users of VS2015 can benefit from the new rules and bug fixes in the SonarC# and SonarVB code analyzers.
Support for projects targeting multiple frameworks
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 Server. The SonarQube Server 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 Server 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).
Running analysis on non-Windows platforms
Command line analysis
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 Server 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.
CI integration in VSTS
The current version (v3) of the SonarQube Server 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 Server and SonarQube Cloud analysis for other types of projects. Currently, the SonarQube Server 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 Server Google group. Alternatively, you can track issues and the current work in progress using the following links: SonarQube for IDE for VS, Scanner for MSBuild, SonarC# and SonarVB code analyzers.