Git Submodule: Warning NU1504: Duplicate 'PackageReference' items found

[Mike-E-angelo]

I have a submodule that is under my solution. Both my solution and the submodule have their respective Directory.Packages.props files. On build in Azure DevOps I get dozens of messages such as these:

##[warning]Framework\DragonSpark\DragonSpark.csproj(0,0): Warning NU1504: Duplicate 'PackageReference' items found. Remove the duplicate items or use the Update functionality to ensure a consistent restore behavior. The duplicate 'PackageReference' items are: Nerdbank.GitVersioning , Nerdbank.GitVersioning .

I am wondering if there is a way to address this rather than ignoring NU1504. Thank you for any assistance you can provide

[Mike-E-angelo]

Wondering if this is a bug and I should report an issue instead? 🤔

[zivkan]

I'm not sure why this discussion didn't come up in my notifications, I just happened to look at discussions while searching for something else. Anyway, no, it's not a bug. Imagine if a project has two PackageReferences, but each are specifying a different version. Which one should NuGet use? Plus, due to the architecture of Visual Studio, NuGet will only be told of one of the two, so whatever logic NuGet tries to use to resolve the duplicate on the command line, NuGet doesn't have that opportunity in Visual Studio.

Sorry if this sounds too obvious, but the solution is to not use duplicates. You can use https://msbuildlog.com to look at a trace of what MSBuild did. Within the tool, you can right click a project and select Preprocess (you can also do this on the CLI with dotnet msbuild my.csproj -pp:pp.txt, then open pp.txt), which will resolve all MSBuild <Import statements, to make one project file with zero external dependencies, and then you can search it for Include="Nerdbank.GitVersioning" to find the two duplicates and then decide how you want to resolve it.

[Mike-E-angelo]

Hi @zivkan thank you for your assistance. For further clarity, I know where the duplicates are: 1 is in the root where the SLN is, and the other is in the submodule. The SLN needs it for its own purposes, and so does the submodule as it can be in any number of other SLNs. I an open to any suggestions on how to address this.

[zivkan]

Use some sort of condition to only add a package reference if the package reference doesn't already exists. Here's MSBuild's docs on how to check item metadata: https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditions?view=vs-2022#metadata

I believe the metadata name for the value that you provide in Include= is called Identity.

The exact syntax for the condition, I don't know as this isn't something many people use, so I'm not familiar. But I suspect you'll be able to find answers on stack overflow with the right search keywords.

[Mike-E-angelo]

Indeed I am familiar with MSBuild conditions, but this seems unnecessary and a lot of work. Unless I am fundamentally misunderstanding the task, I would essentially have to do this for all references as it is not known the references the submodule uses or will add in the future to generate another warning.

As mentioned, I have dozens of these warnings from overlapping references between the primary and submodule. It seems like the packaging would better handle this scenario and/or only throw a warning if different versions are found between the duplicates. In any case, I have swept this under the rug with a NoWarn rule as that seems like the simplest solution here. 😅