I have working on getting a Windows 10 Universal application analysed with SonarQube 6.x as part of a VSTS build. The problem has been that when the VSTS task to complete the SonarQube analysis ran I kept getting an error in the form
WARNING: Duplicate project GUID: "8ace107e-8e3c-4a1b-9920-e76eb1db5e53". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. Project file: E:\Build1\_work\58\s\BlackMarble.Victory.Common.Module.csproj
… plus loads more similar lines.
The exclude flag has been set so the project will not be analyzed by SonarQube. Project file: E:\Build1\_work\58\s\BlackMarble.Victory.Ux.Common.csproj
… plus loads more similar lines.
WARNING: Duplicate project GUID: "1e7b2f4e-6de2-40ab-bff9-a0c63db47ca2". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. 2017-06-09T15:50:41.9993583Z ##[error]No analysable projects were found but some duplicate project IDs were found. Possible cause: you are building multiple configurations (e.g. DEBUG|x86 and RELEASE|x64) at the same time, which is not supported by the SonarQube integration. Please build and analyse each configuration individually.
Generation of the sonar-properties file failed. Unable to complete SonarQube analysis.
Turns out the issue was that even though my CI build was only set to create an x86|Debug build the act of creating the .APPX package was causing both x64 and ARM builds to be build too, this was too much for SonarQube as it though I had a multiplatform build..
The answer was to pass a parameter into the Visual Studio build task to disable the creation of the .APPX package.
The parameter override required is /p:AppxBundle=Never. This overrides the setting of Always that was set in the .CSProj file.
Once this change was done analysis completed as expected. Just need to fix all the issues it found now!
I wanted to add some level of static analysis to our Typescript projects, TSLint being the obvious choice. To make sure it got run as part of our build release process I wanted to wire it into our SonarQube system, this meant using the community TSLintPlugin, which is still pre-release (0.6 preview at the time of writing).
I followed the installation process for plugin without any problems setting the TSLint path to match our build boxes
Within my TFS/VSTS build I added three extra tasks
- An NPM install to make sure that TSLint was installed in the right folder by running the command ‘install -g tslint typescript ‘
- A pre-build SonarQube MSBuild task to link to our SonarQube instance
- A post-build SonarQube MSBuild task to complete the analysis
Once this build was run with a simple Hello World TypeScript project, I could see SonarQube attempting to do TSLint analysis but failing with the error
2016-07-05T11:36:02.6425918Z INFO: Sensor com.pablissimo.sonar.TsLintSensor
2016-07-05T11:36:07.1425492Z ##[error]ERROR: TsLint Err: Invalid option for configuration: tslint.json
2016-07-05T11:36:07.3612994Z INFO: Sensor com.pablissimo.sonar.TsLintSensor (done) | time=4765ms
The problem was the build task generated sonar-project.properties file did not contain the path to the TSLint.json file. In the current version of the TSLint plugin this file needs to be managed manually, it is not generated by the SonarQube ruleset. Hence is a file in the source code folder on the build box, a path that the SonarQube server cannot know.
The Begin Analysis SonarQube for MSBuild task generates the sonar-project.properties, but only adds the entries for MSBuild (as its name suggests). It does nothing related to TsLint plugin or any other plugins.
The solution was to add the required setting via the advanced properties of the Begin Analysis task i.e. point to the tslint.json file under source control, using a build variable to set the base folder.
Once this setting was added I could see the TSLint rules being evaluated and the showing up in the SonarQube analysis.
Another step to improving our overall code quality through consistent analysis of technical debt.