We've been seeing duplicate package references added when installing/updating packages i.e. packages.config contains two package elements with the same id.
Sometimes it happens on the build agent (TeamCity), we are using package restore and the TC Nuget Installer build step. But I just had it happen after calling install-package from the VS package manager console.
Unfortunately I can't provide a scenario that will reproduce it. Has anyone else seen this?
(NuGet 1.6)
Comments: Similar issue I've been tracking down today: I have a project in a solution that fails to build, because of a perfect storm of little issues. I traced it down to ProjectFactory.ProcessTransformFiles(), line 472, where builder.Files contains duplicate entries, which blows up the call to builder.Files.ToDictionary(...). The duplicate files came from me explicitly listing the build outputs in the <files> section of the .nuspec. The funny thing is, this duplicate-files situation appears to be tolerated everywhere else. There even appear to be processes elsewhere in the code that filter them out. But if you happen to have a packages.config, the codepath through ProjectFactory.ProcessDependencies is followed, which calls the fatal ProcessTransformFiles(). The ideal solution would be to trap duplicates *as they're added* to the various collections within the project, and provide *useful, descriptive* diagnostics when they fail.
Sometimes it happens on the build agent (TeamCity), we are using package restore and the TC Nuget Installer build step. But I just had it happen after calling install-package from the VS package manager console.
Unfortunately I can't provide a scenario that will reproduce it. Has anyone else seen this?
(NuGet 1.6)
Comments: Similar issue I've been tracking down today: I have a project in a solution that fails to build, because of a perfect storm of little issues. I traced it down to ProjectFactory.ProcessTransformFiles(), line 472, where builder.Files contains duplicate entries, which blows up the call to builder.Files.ToDictionary(...). The duplicate files came from me explicitly listing the build outputs in the <files> section of the .nuspec. The funny thing is, this duplicate-files situation appears to be tolerated everywhere else. There even appear to be processes elsewhere in the code that filter them out. But if you happen to have a packages.config, the codepath through ProjectFactory.ProcessDependencies is followed, which calls the fatal ProcessTransformFiles(). The ideal solution would be to trap duplicates *as they're added* to the various collections within the project, and provide *useful, descriptive* diagnostics when they fail.
