Ein Element mit demselben Schlüssel wurde bereits hinzugefügt, während das NuGet-Paket installiert wurde

Question

In meinem Projekt verwendete ich die Klassenbibliothek. Nun habe ich diese Klasse lib als NuGet-Paket erstellt, die class lib entfernt und beim Versuch, das Paket zu installieren, erscheint dieser Fehler: "Ein Element mit demselben Schlüssel wurde bereits hinzugefügt"?

Answer 1

In meinem Fall sah ich diesen Fehler, wenn meine packages.config-Datei doppelte Paket-IDs enthielt, die nicht zulässig ist.

Sie können das folgende PowerShell-Skript verwenden, um alle doppelten Pakete in Ihrer Lösung zu finden. Es sucht rekursiv nach allen packages.config-Dateien und nach der Datei packages.config sucht es nach doppelten Paket-IDs.

$solutionFolder = "C:\MySolution" 
$nugetPackageFile = "packages.config" 

$files = Get-ChildItem -Path $solutionFolder -Filter $nugetPackageFile -Recurse 

foreach ($file in $files) 
{ 
    [xml]$xml = Get-Content $file.FullName 
    $nodes = Select-Xml "/packages/package/@id" $xml 
    $packageIds = @{} 

    foreach ($node in $nodes) { 
     $packageId = $node.Node.'#text' 
     try 
     { 
      $packageIds.Add($packageId, $packageId) 
     } 
     Catch [System.ArgumentException] 
     { 
      Write-Host "Found duplicate package in " $file.FullName ". Duplicate package: $packageId" 
     } 
    } 
} 

Answer 2

Ich hatte den gleichen Fehler und es wurde behoben, nachdem ich NuGet selbst aktualisiert. Verwenden Sie das Dialogfeld Extras -> Erweiterungen und Updates, um NuGet zu aktualisieren.

Answer 3

Ich hatte das gleiche Problem. Es sagte mir immer wieder, dass "ein Artikel mit dem gleichen Schlüssel bereits hinzugefügt wurde", obwohl es nicht in meinen Referenzen und nicht in meiner packages.config entweder war.

Schließlich konnte ich es beheben, indem ich alle Dateien in Visual Studio zeigte. Im Ordner bin fand ich dann einen Verweis auf die .dll, die ich über Nuget installieren wollte. Nach dem Entfernen dieses Problems war das Problem verschwunden.

Vielleicht behebt dies auch für Sie.

Answer 4

Ich hatte auch das gleiche Problem. Ich habe das Paket entfernt und das folgende Element aus der Datei Web.Config entfernt und dann das Paket zurück installiert - Problem gelöst!

section name = "AjaxControlToolkit" type = "AjaxControlToolkit.AjaxControlToolkitConfigSection, AjaxControlToolkit"

Answer 5

Ich habe dieses Problem auf einer Reihe von Gelegenheiten habe, wenn der Code von einem anderen Entwickler aufnimmt. Die von anderen Benutzern erwähnten Probleme sind einige der Dinge, auf die ich gestoßen bin. Also hier ist eine Liste der Dinge, die ich in der Vergangenheit getan haben, diese zu lösen, und auch eine neue, den ich gerade über gekommen sind:

• Restart Visual Studio, NuGet manchmal verweist die falschen Dateien aus irgendeinem Grund (eine sehr häufige Situation und Lösung)
• aktualisiert NuGet-Manager in Extras> Erweiterungen und Updates ... (wie von @ravinsp erwähnt)
• reinigen und Ihre Lösung neu erstellen. Alte Dlls können Dinge durcheinander bringen (wie von @Jules erwähnt)

• Suchen Sie nach doppelten Referenzen mit VERSCHIEDENE Versionen in packages.config - obwohl Sie versuchen, ein komplett anderes Paket zu installieren, könnte dieser Fehler durch einen anderen verursacht werden Paketproblem. Ich habe versucht, OctoPack zu installieren, und bekam diesen Fehler, aber es wurde von System.Spatial verursacht. Mein packages.config hatte diese beiden Zeilen in ihm:

  <package id="System.Spatial" version="5.6.2" targetFramework="net45" />

  <package id="System.Spatial" version="5.6.4" targetFramework="net45" />

Answer 6

Wenn man in dem .Net-Core Dilettantismus und.Diese Art von Fehlern tritt nur allzu oft auf.

Für mich verpacke ich normalerweise alle meine Querschneidereien als meine eigenen modularen Pakete. Ich finde, dass, wenn meine Pakete viele andere Abhängigkeiten enthalten, das Hinzufügen der Paketabhängigkeit durch Ändern des project.json-Abhängigkeiten-Abschnitts unglaublich fehlerhaft ist und das oben beschriebene Verhalten ergibt.

Viel zu oft ist die Antwort, alle Abhängigkeiten zu entfernen und das richtige NuGet-Paketverwaltungstool zu verwenden, um die Pakete aus meinem privaten Feed hinzuzufügen, was zu dem Bedingungsdialog für die externen Abhängigkeiten von Microsoft führt.

Es ist nicht ungewöhnlich, die CLI vollständig löschen und neu erstellen zu müssen!

.Net Core und Standard sollte niemals RTM markiert sein. Hoffentlich wird alles besser werden, wenn .Net Standard 2.0 eine Realität wird, aber für den Moment, wenn Sie mit .Net Standard und Core einen Stab aufbauen. Ich weiß genau, wie Sie sich gerade fühlen und hoffentlich hilft Ihnen diese Antwort gut ...