Spurious "not added because the package already contains file" warnings

[dougbu]

This is really two bugs: The files chosen automatically for inclusion when packing may contain duplicates. And, NuGet.exe emits warnings about the duplicates despite the user making no explicit choices.

Though these are "just warnings" it's very annoying, especially when a repo contains lots of packable projects. And, affected solutions have no workaround except completely changing the layout of their output folders.

/cc @rohit21agrawal @emgarten
/fyi @anurse

Details about Problem

• NuGet.exe
• NuGet version: 4.3.0.4406
• OS version: Win10 Enterprise v1703 (15063.632)
• Worked before?: Not sure when it worked. But, it must have because the directory layout involved has been really common in our (Microsoft's) solutions.

Detailed repro steps so we can see the same problem

1. Clone the aspnet/WebHooks repo
2. .\build.cmd

Expected

Clean build

Actual

About 130 warnings, all similar to

EXEC : warning : File 'WebHooks\bin\CodeAnalysis\Test\Microsoft.AspNet.WebHooks.Common.dll' is not
 added because the package already contains file 'lib\net45\Microsoft.AspNet.WebHooks.Common.dll' [WebHooks\src\Packages\Packages.proj]

Other suggested things

Likely root cause

Problem is caused by nesting of output directories and the wildcard search in PackCommandRunner’s GetFiles(…) method.

In this solution, most projects use an $(OutputPath) setting to $(WebHooksRootPath)bin\$(Configuration)\ in tools\WebHooks.settings.targets. Test projects individually (e.g. here) set $(OutputPath) to ..\..\bin\$(Configuration)\Test\. In other words, the test projects write assembly files et cetera into a subdirectory of the usual output folder.

WebHooks\bin\CodeAnalysis content

WebHooks\bin\CodeAnalysis\Test content

Sample Project

• aspnet/WebHooks

[headsphere]

Hey guys - any workarounds for this issue? Or an ETA for a fix?
Thanks!

[dougbu]

@headsphere in WebHooks, our workaround was moving the test assemblies from bin\$(Configuration)\Test to bin\Test\$(Configuration). The workaround means the test assemblies are no longer below the product assemblies in the directory tree and NuGet doesn't see "extra" assemblies.

[dougbu]

"Sees" was incorrect in previous comment. Fixed.

[commonsensesoftware]

In completely different scenario, but with related behavior, this also happens for sources packed in symbol packages when partial type files are used. In my case, I'm using shared projects (*.shproj), but I'm willing to bet the same thing would happen with linked files. As far as I can tell, the flagged duplicate is completely omitted, which is wrong. The file is not a duplicate.

You can observe the behavior in ASP.NET API Versioning with:

msbuild /v:m /t:Build;Pack