[Previous posts]: Build Tasks for SonarQube Analysis, MSBuild and Team Foundation Server integration with SonarQube: version 1.0 released
_
Today, SonarSource released the MSBuild.SonarQube.Runner 1.0.1, along with the SonarQube C# Plug-in 4.2, and the SonarQube Setup Guide for .NET Users version 1.2.0.
This release contains many bug fixes based on your feedback. The main themes are:
- More robust execution,
- more succinct console output,
- better error messages in the event of various failures,
- better detection of test projects,
- better detection of generated code,
- updated and extended documentation.
More robust execution
- The analysis no longer fails if the quality profile contains special characters such as “#”
- If you had tried to use SonarQube to analyze .Net projects before we released the MSBuild.SonarQube.Runner (before April), you would have installed the SonarQube “Visual Studio Bootstrapper plug-in”. Since we introduced the MSBuild.SonarQube.Runner, this plug-in was obsoleted. You should not use it, unless you are still using Visual Studio 2005 or Visual Studio 2008 which are not supported yet by the MSBuild.SonarQube.Runner. As of version 1.0.1, the MSBuild.SonarQube.Runner forcibly disables the old VS Bootstrapper plug-in to avoid any confusion.
- The SonarQube.Analysis.xml file is no longer locked when reading it. This used to be a source of contention in the case of many parallel builds (for example several nightly builds started at the same time).
- The analysis no longer fails if Visual Studio is not installed on your build / agent machine. The consequence is only that you won’t have the code coverage if you run tests.
More succinct console output
The output produced by version 1.0 of the MSBuild.SonarQube.Runner was very verbose. This had the drawback of generating very big log files, some of which were too big to be opened directly in the build summary in Visual Studio Online (although the complete logs could be downloaded and viewed) . In version 1.0.1 we reduced the level of detail produced in normal operations.
If you want to enable verbose log files, you can do it by setting the sonar.verbose property to true. This is particularly useful if you want to report a bug:
MSBuild.SonarQube.Runner begin /n:ProjectName /v:1.0 /k:ProjectKey /d:sonar.verbose=true
Better error messages in the event of various failures
- With the past version, if you tried building multiple configurations, you received a cryptic error. The error message is now explicit.
- When using a self-signed HTTPS certificate for the SonarQube's server, you got a security exception. Now there is an actionable message explaining what you can do on the build machine to accept this untrusted certificate (install the self-signed certificate on the machine)
- In case of errors, the sonar-runner stack trace is now always generated (which can help us investigating the errors you report)
- In case the SonarQube server URL was wrong (for instance incorrectly escaped), there were cases where the web exception was silently ignored, making investigating the issue difficult. The message is now more explicit enabling you to easily recognize incorrect URLs
- You will now be notified if you use a SonarQube project key with forbidden characters (for instance spaces)
Better detection of test projects
- If you were analyzing a Visual Studio solution located in a parent folder which name contained (“test”) – a typical scenario if you were trying out SonarQube – the analysis ended-up being empty. This was very confusing for a first experience. The root cause of this unwanted behavior was that the discovery of Test projects assumed that any project located in a folder containing “test” in the name was a test, and the analysis is not the same for test projects and product code projects (the rules are different). We changed the default regular expression so that it now only picks-up paths where the project filename contains the word 'test'. The rest of the path is ignored (you can still change the regular expression – see the documentation for more information).
Better detection of generated code
- Since the first version of the MSBuild.SonarQube.Runner, generated files are automatically excluded from the analysis. Those can be files generated by a single file generator in Visual Studio (.cs file generated from .resx files for instance). In MSBuild.SonarQube.Runner v1.0.1 the files generated from XAML (in fact, any files generated to the obj folder) will also be ignored.
Updated and extended documentation
- Even if generated files are excluded, you might want to exclude more files or even whole projects. The ”Excluding artefacts from analysis” section of the online documentation explains how to exclude/skip a specific MSBuild Projects or files from a SonarQube analysis.
- If you are comfortable with customizing their MSBuild projects, there is a new appendix Appendix 3: Advanced MSBuild SonarQube Runner Configuration that describes how to use the features of MSBuild to customize the analysis process in more advanced scenarios
- Explanation was provided on how to specify a relative path for instance to a code coverage report or a ReSharper report (using the %CD% variable)
We look forward to hearing from you. Please send us your feedback either by asking some questions on StackOverflow or directly reporting some bugs on SonarQube Google Group. You can also propose suggestions on what you would like us to do next, for instance from User Voice.
Thank you!