Duplicate ProjectGuid: "00000000-0000-0000-0000-000000000000" on dotnet core scan

When using SonarQube Extension for VSTS/TFS I found the step to run code analysis fails if the dotnet core 2.1 build step references /.csproj since the projectGuids are located in the sln. This works if you modify the dotnet core build to build the *.sln instead

Hi @Rob_Young,

The Scanner for MSBuild requires unique identifiers for each analyzed project to be able to consistently match the analysis results and the SonarQube data. The <ProjectGuid> element is (was) a very good candidate for uniqueness because Visual Studio automatically assigns it when you create a new project. The .NET Core projects do not have <ProjectGuid> element by default and that’s why the analysis works only if you analyze the solution, which silently “assigns” unique GUIDs for the projects.

Other way to solve the problem is to add unique <ProjectGuid>GUID</ProjectGuid> elements in each project. This way you will be able to analyze separate projects without a solution.

This limitation is mentioned in the documentation.

Cheers,
Valeri

I see reading this page that it says “Single .NET Core project files will not be analyzed unless a unique guid is added to the csproj”. However, I have found that the guid is specified in the sln so that if that is referenced instead of the csproj the scanner will work without requiring the workaround. I think the documentation needs to be extended to state that project files which are part of a solution shouldn’t be referenced directly but the sln file should be the reference which will pass in a valid guid upon scanning each project. In should be done in the dotnet build properties by passing the sln file only and not the csproj file list.

regards

Rob

I updated the documentation article, please, let me know if you think that I need to add more explanations.

1 Like

that look’s perfect - it could help a lot for people to know that.

Rob

1 Like

Sorry for opening an old thread but there is (at least) one other situation where this occurs–even when building with the .sln file. If the sln has two or more projects, I added this to one csproj to reference the other csproj to fix a build ordering problem:

<ItemGroup>
    <ProjectReference Include="..\citation-service\citation-service.csproj"> 
        <ReferenceOutputAssembly>false</ReferenceOutputAssembly> 
    </ProjectReference>
</ItemGroup>

The idea for this solution to my build ordering problem came from https://devblogs.microsoft.com/visualstudio/incorrect-solution-build-ordering-when-using-msbuild-exe/.