Bdtjtk

I will preface this that my current solution to this is very easy but one I do not want to keep implementing.

The Problem

Below you will see an image outlining my current build steps. Each of these contain the default settings, with the Prepare analysis on SonarQube setup to point to my endpoint.

When I run this, again just default settings, I am presented with the following errors

WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube. Project file: "D:a1sAPI.Tests.csproj"

WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube. Project file: "D:a1sAPI.csproj"

This is because the build step for dotnet core, by default, looks for **/*.csproj using the linked setting (Parameters.RestoreBuildProjects) - with the update to the csproj format the project guid is no longer stored in the csproj files. What I suspect is happening is that SonarQube just defaults the guids when it finds nothing defaults to 000... and then throws this error.

The Fix

Unlinking the Path to project(s) parameter and pointing to **/.*.sln fixed the issue, because now SonarQube can see the project guids (defined the .sln)

The Question, finally

After that long winded explanation I am lead to ask if there is a better way to get SonarQube to recognise dotnet core projects.

I do not want to change the default build task every time I create a project to satisfy SonarQube's requirements.

$paths = Get-ChildItem -include *.csproj -Recurse

foreach($pathobject in $paths) 

{

    $path = $pathobject.fullname

    $doc = New-Object System.Xml.XmlDocument

    $doc.Load($path)

    $child = $doc.CreateElement("ProjectGuid")

    $child.InnerText = [guid]::NewGuid().ToString().ToUpper()

    $node = $doc.SelectSingleNode("//Project/PropertyGroup")

    $node.AppendChild($child)

    $doc.Save($path)

}

The simplest approach is to create a build template as @jessehouwing suggests.

The comments in this SO question explain why SonarQube needs a stable unique id for each project. There isn't currently a flag you can pass to the tasks to tell the Scanner for MSBuild to use an alternative identity if there isn't a project guid. It also isn't obvious what could be used as an alternative id: the file path to the project isn't stable, and the project name isn't guaranteed to be unique and can change so it isn't stable either.

FYI the SonarCloud extension for VSTS now includes a minimal template for .NET Core projects to help new users try out analysing projects. That template has the build parameter set to **/*.sln, and some of the non-essential build steps removed (e.g. publishing artefacts). It's intended to allow new users to try out analysing code without having to set up any machines and with a minimum of configuration (i.e. using VSTS + SonarCloud + hosted build agent as described in this HOL).

We didn't add templates to the SonarQube extension because that's not a zero-installation option, and adding a template didn't seem to add much value. If you think it would be useful, you could make a suggestion on the SonarSource Community forum.