NuGet doesn't error when packaging nuspec with duplicate files.

[ericstj]

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):
nuget.exe

NuGet version (x.x.x.xxx):
4.6.2.5055

Detailed repro steps so we can see the same problem

1. Download and unzip
   badPackage.zip

2. Run nuget pack on the nuspec inside.

Expect: failure due to duplicate files
Actual: successfully creates a package with duplicates.

[mishra14]

cc @rohit21agrawal

[zkat]

@JonDouglas @nkolev92 at face value, fixing this as suggested is a breaking change. An alternative suggestion that we could do now without risking breaking anyone is to manually dedupe these files before writing out the nupkg, so the last file with a certain path "wins", and only one ever makes it into the nupkg itself.

Or I could just validate and throw. I'm not sure how many people this would break, but it might certainly be surprising.

This does look like it's breaking the server, at least, so I don't imagine it's all that common: NuGet/NuGetGallery#7744

[zkat]

cc @zivkan too

[JonDouglas]

I think breaking this experience is ideal given that it is not deterministic of what file "wins". I think validating this and providing a warning/error is a path forward. We should inform the package authors in these scenarios to only include one file?

[zkat]

yeah. I'll hack that up and we can take a look and see how we feel about it :)

@ericstj do you have any particular opinion on this beyond wanting it to fail?

[andrew-polk]

This breaking change is not documented in the release notes as a breaking change.

While I somewhat understand your decision to treat packages broken by this change as containing a "bug" due to having nondeterministic contents, in our case, we were simply finding the same file twice with two different globs. Thus there was no problem with the output.
Thus this undocumented breaking change broke our build process for no benefit.

[DannyMeister]

We are another case of finding the same file a few times via wildcards in some of our large nuspecs where we've been transitioning to wildcards to make maintenance more manageable. This is a thing which can occur frequently given how VS projects copy their dependencies into each library bin that you build. We haven't though of a good way to cope with this yet.

This change has brought down our CI. Please give a little more weight to considering breaking changes going forward. Kind of a nightmare when the fix requires us either to pin the nuget version in our CI scripts across many active support branches, or fix our nuspecs across all those branches.

[watters]

I think the fix here may be erroring out in situations that aren't actually problematic. The reported bug complains about a duplicate file coming from two different source locations.

The fix here appears to error when there are multiple entries for the exact same source file (can happen with overlapping wildcard specifiers), which wasn't previously resulting in duplicate files in the destination package.