SonarQube dotnet core: how to avoid the duplicate guid error without altering the default build task

projectguid .net core
sonarqube net core code coverage
guid generator

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:\a\1\s\API.Tests.csproj"
WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube. Project file: "D:\a\1\s\API.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)
}

SonarQube dotnet core: how to avoid the duplicate guid error , SonarQube dotnet core: how to avoid the duplicate guid error without altering the default build task - .net-core. Read from build system for Maven, Gradle, MSBuild projects. Else default to empty. sonar.sourceEncoding: Encoding of the source files. Ex: UTF-8, MacRoman, Shift_JIS. This property can be replaced by the standard property project.build.sourceEncoding in Maven projects. The list of available encodings depends on your JVM. System encoding

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.

Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000 , SonarQube dotnet core: how to avoid the duplicate guid error without altering the I do not want to change the default build task every time I create a project to  Default is default system encoding #sonar.sourceEncoding=UTF-8 Run the following command from the project base directory to launch the analysis: sonar-scanner. Sample Projects. To help you get started, simple project samples are available for most languages on github. They can be browsed or downloaded. You'll find them filed under sonarqube

Building on Artur Mustafin solution, I took that and put it inside a powershell step. I also check for the node incase you have a mix of .net and core

- powershell: |
   $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")
       if ($node)
       {
           $node.AppendChild($child)
           $doc.Save($path)
       }
   }
  workingDirectory: '$(Build.SourcesDirectory)'
  displayName: 'Add Project GUIDs'

dotnet-sonarscanner fails with duplicate ProjectGuid message if , When using SonarQube Extension for VSTS/TFS I found the step to run code analysis This works if you modify the dotnet core build to build the *.sln instead NET Core projects do not have <ProjectGuid> element by default and that's why the instead of the csproj the scanner will work without requiring the workaround. Omitting this task will not affect the analysis results on SonarQube - it simply means the Azure DevOps Build Summary page will not show the status of the analysis or a link to the project dashboard on SonarQube.

SonarScanner for Azure DevOps, NET Core version of the Scanner for MSBuild Post-processing started. pipeline when 'dotnet build' and 'dotnet test' are before the 'end' step on May 22, 2019 duncanp-sonar changed the title dotnet-sonarscanner fails in azure pipeline fails with duplicate ProjectGuid message if 'dotnet test' is run without the --no-​build  By using Nullable<Guid>, default becomes null instead of Guid.Empty. Some times, adding Nullable<T> can make it clearer when a value is present or absent. Other times, adding Nullable<T> can create extra cases to check that aren't necessary, and only serve to create potential sources of errors.

SonarScanner for MSBuild, Improve detection of duplicated coverage reports, update to SonarScanner 4.3 Each extension provides three tasks you will use in your build  4 Automatically Tagging a PR Build in Azure Devops Nov 23 '18 4 Serving multiple tensorflow models using docker Oct 29 '18 3 Timing / Framing issue with Jasmine-marbles using hot and cold Feb 15 '18

Azure devops sonarqube code coverage, Improve detection of duplicated coverage reports, fix categorization of Net Core multi-platform projects and it can be used on non-Windows platforms. MSBuild.​dll> begin /k:"project-key" dotnet build <path to solution.sln> The begin step is executed when you add the begin command line argument. However, hard to read and brittle unit tests can wreak havoc on your code base. This article describes some best practices regarding unit test design for your .NET Core and .NET Standard projects. In this guide, you'll learn some best practices when writing unit tests to keep your tests resilient and easy to understand.

Comments
  • Have you considered creating a template or task group that is configured correctly so you can just use that?
  • @jessehouwing I have and, again, I don't particularly want to do that if there is a simpler way (such as adding an argument to one of the SonarQube tasks, or something else). I feel like SonarQube should support this out of the box / with some configuration otherwise every developer out there will have to do the same as I am.
  • Send them a pull request: github.com/SonarSource/sonar-scanner-vsts
  • You have to create ProjectGuid one using script stackoverflow.com/a/52557954/570598
  • github.com/SonarSource/sonar-scanner-msbuild/issues/659 Coming soon... maybe.
  • The easiest option to me would be to add a flag and an pointer to the solution file in the Prepare analysis step. That way SonarQube can have an idea of the project id's. Something like Is dotnet core if yes you add the solution file pointer. Sonarcloud costs far more than the self hosted option so isn't something I can consider.
  • That doesn't sound any quicker or easier than changing the build definition to build */.sln, and is less discoverable. BTW why do you need to unlink the build parameter? Why not just edit the parameter at process level to use */.sln instead?
  • It is just as easy, and more importantly it is a configuration setting on SonarQube rather than a configuration setting on a default task for dotnet core. I can't provide any evidence for this but I suspect most people are fine with the defaults and don't change them - I feel like the solution should be something that does not rely on another task being configured correctly for it to function, but I'm probably being pedantic. Changing the parameter would work, but my point about configuration still stands.
  • I agree it would be better if it wasn't necessary to change the task defaults. However, I think adding another setting etc would generate more support issues than it would remove.
  • You could be right. I'll speak to my team and see what we want to do with this info. Thanks for the options.