MSBuild.SonarQube.Runner v1.0.2 released (and renamed)
Yesterday, SonarSource officially released SonarQube C# Plugin 4.3 and version 1.0.2 of the MSBuild.SonarQube.Runner. An updated version of the MSBuild.SonarQube.Runner documentation has also been released.
Readers who have seen the SonarSource announcement might have noticed that it refers to the SonarQube Scanner for MSBuild. This is the new name for the MSBuild.SonarQube.Runner, although it will take some time for all of the documentation and code to be fully updated to use the new name.
Version 1.0.2 is a minor release that contains a number of bug fixes. The main changes are as follows:
Credential information is no longer stored by the Runner Scanner
- Previously, any credentials (i.e. sonar.login, sonar.password, sonar.jdbc.username and sonar.jdbc.password) passed on the command line would be stored in plain text in the temporary files. This is obviously not ideal from a security point of view so now the credentials are not stored (and do not appear in the logs either). A consequence of this change is that if you do pass credentials on the command line in the begin phase then you will also need to explicitly pass the credentials in the end phase. Similarly, if you pass credentials in the “Pre-build script arguments” section in a TFS XAML Build you will also need to pass the credentials in the “Post-test script arguments”. No configuration changes are necessary if you are using the Build vNext tasks.
Relative path arguments are resolved relative to the current command line directory
- When analysing from the command line, relative path arguments (such as the location of a Resharper report file) are now correctly resolved relative to the current directory. Previously, the paths were incorrectly resolved relative to an internal working directory created by the scanner, which effectively made it impossible to use relative paths.
- The recommendation when using Team Build (both XAML builds and the new Build system) is still to use environment variables provided by the build system to specify full paths, rather than using relative paths.
Compatibility with different versions of MSBuild clarified
- The SonarQube documentation has been updated to help clarify the compatibility between the different versions of the MSBuild.SonarQube.Runner, the C# and VB plugsins, MSBuild and Visual Studio. To summarise, you will need at least MSBuild 12.0 and .Net 4.5.2 to successfully use all the features of the latest version of the scanner and the plugins. However, this does not stop you from building assemblies that are designed to run on earlier versions of the .Net Framework.
C# plugin analysis rules updated
- The SonarQube C# plugin has been updated to include SonarLint for Visual Studio 1.3.0 which brings new rules and some bug fixes to the existing analysis rules.
Going forwards, there are a couple of main areas that we are looking at, namely closer integration with Visual Studio, and running Roslyn analysers as part of the build phase rather than in the end phase. See the [SonarQube Integration Plans][9] post for more info.
[Other related posts: Build Tasks for SonarQube Analysis, Quickstart: Analyzing .NET projects with SonarQube, MSBuild or Visual Studio Online, and third-party analyzers (StyleCop, ReSharper), The Maven build task now simplifies SonarQube analysis]
Light
Dark
0 comments