Подтвердить что ты не робот

Элемент с тем же ключом уже добавлен во время установки пакета NuGet

В моем проекте я использовал библиотеку классов. Теперь я сделал этот класс lib как пакет NuGet, удалив библиотеку классов и при попытке установить пакет появляется эта ошибка: "Элемент с тем же ключом уже добавлен"?

4b9b3361

Ответ 1

В моем случае я видел эту ошибку, когда файл package.config содержал дубликаты идентификаторов пакетов, которые не разрешены.

Вы можете использовать PowerShell script ниже, чтобы найти все дубликаты пакетов в вашем решении. Он находит все файлы packages.config рекурсивно и в файле packages.config, он проверяет наличие дубликатов идентификаторов пакетов.

$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"
        }
    }
}

Ответ 2

У меня была такая же ошибка, и она была исправлена ​​после того, как я обновил NuGet. Используйте диалоговое окно "Инструменты → " Расширения и обновления "для обновления NuGet.

Ответ 3

У меня была эта проблема в ряде случаев при сборе кода от другого разработчика. Проблемы, упомянутые другими пользователями, - это некоторые из тех вещей, с которыми я столкнулся. Итак, вот список вещей, которые я делал в прошлом, чтобы решить эту проблему, а также новую, с которой я только что столкнулся:

  • Restart Visual Studio, NuGet иногда ссылается на неправильные файлы по какой-либо причине (очень распространенная ситуация и решение)
  • Обновите NuGet Manager в Инструменты > Расширения и Обновления... (как упоминалось @ravinsp)
  • Очистите и перестройте свое решение. Старый dlls может испортить вещи (как упоминалось @Jules)
  • Проверяйте дубликаты ссылок с версиями DIFFERENT в пакетах .config - даже если вы пытаетесь установить совершенно другой пакет, эта ошибка может быть вызвана другой проблемой пакета. Я пытался установить OctoPack и получил эту ошибку, но это вызвано System.Spatial. В моих пакетах .config были эти две строки:

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

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

Ответ 4

У меня была та же проблема. Он продолжал рассказывать мне, что "элемент с тем же ключом уже добавлен", хотя он не был в моих ссылках, а не в моем packages.config.

В конце концов мне удалось исправить это, показывая все файлы в Visual Studio. Внутри папки bin я нашел ссылку на .dll, которую я пытался установить через Nuget. После удаления этой проблемы проблема исчезла.

Возможно, это исправляет это и для вас.

Ответ 5

Я также столкнулся с той же проблемой. Я удалил пакет и удалил следующий элемент из файла Web.Config, а затем установил пакет обратно - проблема решена!

раздел name= "ajaxControlToolkit" type = "AjaxControlToolkit.AjaxControlToolkitConfigSection, AjaxControlToolkit"

Ответ 6

Если кто-то занимается в .Net Core и .NET Standard Portable Class Library, эти типы ошибок происходят слишком часто.

Для меня я обычно собираю все свои проблемы с перекрестными связями как свои собственные модульные пакеты. Я считаю, что если мои пакеты содержат множество других зависимостей, просто добавляя зависимость пакета, изменяя раздел зависимостей project.json, это невероятно багги, что приводит к описанному выше поведению.

Слишком часто ответ заключается в удалении всех зависимостей и использовании надлежащего инструмента управления пакетами NuGet для добавления пакетов из моего личного канала, что приведет к диалогу условий и условий для внешних зависимостей от Microsoft для рендеринга.

Необязательно удалять и воссоздавать CLI полностью!

.Net Core и Standard никогда не должны быть отмечены RTM. Надеюсь, что все станет лучше, когда .NET Standard 2.0 станет реальностью, но пока, если вы делаете удар в здании с .Net Standard и Core, я точно знаю, как вы себя чувствуете сейчас, и, надеюсь, этот ответ вам хорошо...