Scanner should not require a ProjectGuid

[rickardp]

Description

The scanner forces me to add ProjectGuids to all my new SDK-style MSBuild projects, which is cumbersome to say the least, and is also not in line with the new style projects. The scanner should make away with this requirement.

Repro steps

1. dotnet new console

2. Run scanner on project

Expected behavior

Results are uploaded.

Actual behavior

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

Known workarounds

• In text editor, add unique ProjectGuid to all the projects.
  or
• add the projects to a solution and build the solution instead of the individual projects

[duncanp-lseg]

It should be possible to remove this requirement for SonarQube v7.6 or later, but probably not for earlier versions of SonarQube (to maintain backwards-compatibility with projects that have already been analysed).

Prior to the about-to-be-released version 7.6 of SonarQube, individual MSBuild projects were mapped to to SonarQube modules. The ProjectGuid was used as the unique identifier for the module. The concept of modules was dropped in SonarQube v7.6.

[lg2de]

SonarQube 7.6 is available.
Can we easily generate a GUID internally to get a valid analysis?

[jonathann92]

@duncanp-sonar Just confirming with you, if we upgrade to 7.6 we won't be needing <ProjectGuid> anymore?

[duncanp-lseg]

@jonathann92 unfortunately not. SQ7.6 is the minimum version of SQ that will be able to support projects with without ProjectGuids, but we still need to make some changes in the Scanner for MSBuild.

[jonathann92]

@duncanp-sonar Sorry I had a typo in my above comment I put angle brackets around a word, I meant to say:
if we upgrade to 7.6 we won't be needing ProjectGuids anymore?

In your reply, what do you mean by support projects with ProjectGuids? I believe right now SQ6.7 requires ProjectGuids.

[duncanp-lseg]

...and I wrote "with" instead of "without"... I've edited my previous comment.

[lg2de]

@duncanp-sonar, what kind of changes are required in the Scanner?
I would like to support these changes!
We have started a project completely with .NETCore. Now we need the project GUIDs only for SQ. I would like to remove these GUIDs as soon as possible.

[hueidou]

Another solution is adding a .sln, then dotnet build solutionfile.sln instead of dotnet build projectfile.csproj, sonar-scanner will use the ProjectGuid in .sln.

[rickardp]

@huridou Yes, that was my second workaround in the original issue report. Hoping for the scanner to be fixed though, as msbuild doesn’t use projectguids anymore.

The sln file format is also a hopelessly outdated piece of legacy and its use of project guids is there basically to support the GUI only.
dotnet/msbuild#1730
If MS actually fixes this (maybe when VS code becomes the new VS?) the workaround wouldn’t work anymore. But that probably won’t happen in years.

[CodeSwimBikeRunner]

Is it possible to do a build off .csproj and the scanner work? What do we need to do to fix this?

[mkowalskigps]

Any updates on this given things are up to version 7.9?

[GrimGadget]

This happens in SonarCloud, too.

Even worse, I AM building from a solution file, and still get the warning/error, even if I add ProjectGuid tags to each project I want analyzed. However, if the project file does have a ProjectGuid, it does get analyzed. I just still get the now-meaningless warning in the output.

The only upside to this is that it makes it somewhat easy to have SonarCloud ignore the unit test projects themselves. Just leave out the ProjectGuid tag and the project is ignored for analysis.

[CodeSwimBikeRunner]

How are we doing on this? Pretty important at our enterprise.

[phoenyx2k]

@duncanp-sonar
Any update on this? This is a very bad user experience as the developer has to remember to add a Guid.

[hmz]

Another solution is adding a .sln, then dotnet build solutionfile.sln instead of dotnet build projectfile.csproj, sonar-scanner will use the ProjectGuid in .sln.

We were using the task below and the "projects: '**/*.csproj'" part was the couse of this problem, we removed this part because Build command already builds all of the projects within the solution.

  - task: DotNetCoreCLI@2
    displayName: 'Build'
    inputs:
      command: 'build'
      projects: '**/*.csproj'
      arguments: '--configuration Release'

this works;

  - task: DotNetCoreCLI@2
    displayName: 'Build'
    inputs:
      command: 'build'
      arguments: '--configuration Release'

[alexshikov]

Any plans on supporting this? We've manually added the ProjectGuid to the csproj files, but with any change to the project structure/file this property is removed from the csproj file by studio. Pretty annoying...

[ikemtz]

If it helps anyone, this PowerShell script will find all of your .csproj files and add a ProjectGuid if it's missing.

https://github.com/ikemtz/NRSRx/blob/master/sonarqube-create-project-guids.ps1

In the year that I've been on this project using SonarCloud, I personally haven't seen that VS removes the node.

[alexshikov]

@ikemtz that's an interesting idea, we'll try to convert ps1 script to bash as we are using MacOS to build Xamarin projects.
Unfortunately, my teammate commits that changed with every PR. Seems VS for Mac not so smart.

[ikemtz]

@alexshikov Having to re-add the project guid sounds extremely painful. The funny thing is that I don't even think SonarCloud uses the Project Guid.

[ikemtz]

@alexshikov, I did some thinking, you should be able to use this script with PowerShell core. Also, if you have a CI/CD process in place, you could add this script as a build step before prepping the SonarQube analysis.

[jonathann92]

is there any downside to having a new project guid for a single csproj ever time we do a scan?

[ikemtz]

From what I can tell, that project guid isn't used anywhere; my team has 12 different SonarCloud projects off of a single MonoRepo. Again, from what I can tell, there is zero correlation between the 12 projects, despite the fact that the "core" libraries are shared across all 12.

[timster01]

@ikemtz does your script have any requirements for the working folder the script is run from? I am trying to run it as a pipeline step in an azure environment but the script doesn't give any output and sonarcloud still gives a "no valid guid" error.

[ikemtz]

@timster01 Good question, so the assumption is that the file would be at the same level as your .sln file. The script recursively looks for *.csproj files that exist in child folders.

[timster01]

@ikemtz I have tried running it from both the main project folder which contains folders with the .sln files one layer below and from the folders with the .sln files. I don't see any output from the script and sonarcloud still tells me there are no valid guids. Is there a limit to search depth or something similar?

[ikemtz]

Based on your feedback I made some changes to the script to make it easier to figure out what's going on. Here's the updated version:

https://github.com/ikemtz/NRSRx/blob/master/sonarqube-create-project-guids.ps1

To answer your original question, that I know of (unless there's a PowerShell and/or OS limitation), there is no limit to the depth.

The script basically does a recursive search for "*.csproj" files, treating the location of the script as the starting point (root). Then it opens up the individual .csproj files treating them as XML documents.

For each XML document, It then searches for the ProjectGuid node, if it exists it creates one. If not it then makes sure that the ProjectGuid hasn't been duplicated by another project.

[slimlime]

Thank you for the tips - Took a bit of tracking for new NET Core projects .csproj properties reconciling multiple methods and messages with the sonar-project.properties

[mitoihs]

We've just started using Sonar in my team and that's my first impression - encountering over-year-old issue which seems trivial to fix and me wasting my time to find out what all those new warnings are about. Not very nice.

[ikemtz]

@mitoihs Yeah, I agree the situation is unfortunate, but the items that SonarCloud tends to find make it worth the hassle. This is the only ongoing issue I have with SonarCloud and I was able to script around it.

I just have to remind my team to run the script each time they add a project.

[peteraritchie]

Prior to the about-to-be-released version 7.6 of SonarQube, individual MSBuild projects were mapped to to SonarQube modules. The ProjectGuid was used as the unique identifier for the module. The concept of modules was dropped in SonarQube v7.6.

Reusing Visual Studio implementation details for something they were not designed for doesn't make the design correct.

[rickardp]

@mitoihs Yeah, I agree the situation is unfortunate, but the items that SonarCloud tends to find make it worth the hassle. This is the only ongoing issue I have with SonarCloud and I was able to script around it.

I just have to remind my team to run the script each time they add a project.

We actually stopped using SonarCloud. This issue and how it integrates with C# code (as opposed to Java and all the rest) made it too cumbersome to use. Most of the stuff in SC is already in Roslyn and for the other stuff there is the sonar scanner analyzer, combined with Github status checks.

For us, imposing these quirks on the teams is a no go as we focus hard on reducing noise for devs.

I think SonarQube really need to get the integration issues like this fixed. The workarounds described here are not acceptable and they lose business due to this

[Eli-Black-Work]

@ikemtz Do you still have a working copy of the script somewhere? Thanks :)

[Eli-Black-Work]

Okay, finally got this working! My problem and solution was a bit different from the ones listed above.

We were building a .sln file, not a .csproj file, but we were still getting a message that looked like this: ...\targets\SonarQube.Integration.targets(330,5): warning : The project does not have a valid ProjectGuid. Analysis results for this project will not be uploaded to SonarQube. Project file: ProjectB.csproj

The issue turned out to be that our .sln file contained ProjectA, and ProjectA referenced ProjectB, but ProjectB wasn't included in the .sln file. Adding ProjectB to the .sln file fixed the issue!

[ikemtz]

@Bosch-Eli-Black I just saw your message, glad you were able to resolve the issue.

[mickael-caro-sonarsource]

Hi there, PR for that has just been merged, expect it soon to be release. I'm closing this issue.