WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube

It would be good to get a response to the question below the dotted lines, but as I was submitting this, I found the following: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000" on dotnet core scan

In case this helps anyone else, I resolved the problem by building the solution rather than the main project:

- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    projects: '**/*.sln'
    arguments: '--configuration $(BuildConfiguration) --no-restore'

(note the no-restore option as we restore prior to this).
It’s worth noting that this may not work if the solution has multiple build targets (some of ours do, but I’ve not tested them yet).



I’m trying to run sonarcloud on our .Net Core Solutions via Azure Pipelines (following documentation mentioned here), setup in YML seems correct, but I’m running into the following problem:

WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube. Project file: "D:\a\1\s\xxxxx.xxxxxx.Core\xxxxx.xxxxxx.Core.csproj"
WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube. Project file: "D:\a\1\s\xxxxx.xxxxxx.DataPersistence\xxxxx.xxxxxx.DataPersistence.csproj"
WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube. Project file: "D:\a\1\s\xxxxx.xxxxxx.Services\xxxxx.xxxxxx.Services.csproj"
WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube. Project file: "D:\a\1\s\xxxxx.xxxxxx.Services.Tests\xxxxx.xxxxxx.Services.Tests.csproj"
WARNING: Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000". The project will not be analyzed by SonarQube. Project file: "D:\a\1\s\xxxxx.xxxxxx.Api\xxxxx.xxxxxx.Api.csproj"

This seems a well documented problem: here, here, here

and I can resolve it by running in repo containing the solution:

$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)
}

(from here)

However, this isn’t a great solution as we are building a microservice environment and have many departments, so it’s additional overhead to document and get right. Especially when the projects do have GUIDs inside the solution file already. Is this really the solution? - it seems quite an old problem and the documentation doesn’t mention anything about this.

1 Like

I’m glad you found the documentation useful!

Single .NET Core project files (csproj or vbproj) could be built and successfully analyzed only if a <ProjectGuid>unique guid</ProjectGuid> element is added in the csproj or vbproj XML. The <ProjectGuid> element is not required if you build a solution (sln) containing that project.

Please let us know if and how we could make our docs better

A post was split to a new topic: Assigning GUIDs to C# projects

A post was split to a new topic: Duplicate ProjectGuid, Illegal characters in path

dotnet core is old now, how come sonarqube still relies on GUID in csproj-files .we can´t use sonarcloud for about 75% of our software projects

i will not inject deprecated GUIDs into the csproj-files in the pipelines

Hey @tusk and welcome to the community !

Good news for you, we are working on it, and the next major release of the Scanner (which is due early November) will deal well with .NET Core projects.

Mickaël

thank you, i edited my last answer a bit to look more proper

isn´t it solvable with just a scanner parameter that we can set so it is persistent in the pipelines?

I’m afraid, not,

Or maybe with a powershell script that adds automatically a ProjectGuid to each csproj detected in the sources directory ?

yes, that is the workaround i´ve seen in other threads… it might be applicable to some of our projects, it´s just not a pretty solution

i thought implementing a new parameter for dotnet core projects would solve it… i guess not then

Hello there,

Issue should be fixed by using version 5 and onwards of the Scanner.

Looking forward for your feedbacks.

Thanks !
Mickaël

1 Like