Как отладить / исправить "Сборка с таким же простым именем" уже импортирована

Question

Я использовал Nuget install-package установить пакет (назовем его PackageA) в проект. После установки мой файл project.json выглядит так:

{
  "dependencies": {
    "PackageA": "1.1.15"
  },
  "frameworks": {
    "net45": {}
  },
  "runtimes": {
    "win": {}
  },
  "supports": {}
}

Теперь PackageA имеет косвенную зависимость от PackageC. Nuget успешно устанавливает пакет, но при компиляции выдает ошибку CS1704 "An assembly with the same simple name 'PackageC' has already been imported. Try removing one of the references (...\PackageC.dll) or sign them to enable side-by-side."

Сильное подписание не вариант, по словам людей, которые говорят мне, что делать.

Если я удаляю ссылку, предложенную в сообщении CS1704, я получаю сообщение об ошибке компиляции "Could not copy the file ...\PackageC.dll" because it was not found."

Если я изменю версию PackageA на плавающую версию "*", то Nuget жалуется, что не может разрешить кучу зависимостей. (Я в конечном итоге хочу использовать плавающие версии.)

{
  "dependencies": {
    "PackageA": "*"
  },
  "frameworks": {
    "net45": {}
  },
  "runtimes": {
    "win": {}
  },
  "supports": {}
}

Если я затем укажу свой project.json, эта ошибка исчезнет и CS1704 вернется.

{
  "dependencies": {
    "PackageA": "*",
    "PackageB": "*",
    "PackageC": "*"
  },
  "frameworks": {
    "net45": {}
  },
  "runtimes": {
    "win": {}
  },
  "supports": {}
}

Некоторые дополнительные примечания, чтобы сделать это более запутанным:

1. Все зависимости пакетов также используют плавающие версии.
2. Я пытался очистить кеш Nuget (nuget locals all -clear) но безрезультатно.
3. Установка пакета и компиляция работает нормально, если я угробил project.json и nuget с автоматическим восстановлением. К сожалению, это тоже не вариант.
4. Это ранее работало. Не знаю, что изменилось, что сломало его.

Что я могу сделать, чтобы отладить / исправить это?

Answer 1

Nuget импортировал не последнюю версию пакета (назовем его PackageX), в котором в качестве зависимости использовался PackageC; в свою очередь, была импортирована более старая версия PackageC. Это было источником проблемы.

Я отладил эту проблему, очистив глобальный кеш Nuget и перестроив свое решение. После этого я проверил каждый пакет в кеше c:\users\<me>\.nuget\packages для которых плавающие версии были указаны где-либо в моей цепочке зависимостей. Я сравнил каждую из них с последними версиями в своем личном канале в поисках расхождений. При этом я обнаружил, что устаревшая версия PackageX была кэширована вместе с устаревшей версией PackageC.

Чтобы решить эту проблему, я сделал несколько дополнительных указаний моего project.json, чтобы включить "PackageX": "*" в качестве дополнительной зависимости. Как только я это сделал, из моего личного канала была установлена ​​правильная (последняя) версия PackageX, и компиляция продолжалась без проблем.

Answer 2

Что я могу сделать, чтобы отладить / исправить это?

Эта ошибка указывает на то, что две ссылки имеют одинаковые идентификаторы сборок, поскольку в рассматриваемых сборках отсутствуют строгие имена, они не подписаны, и, следовательно, компилятор не может различить их в метаданных. Таким образом, среда выполнения игнорирует свойства имени версии и сборки культуры. Вы можете обратиться к ошибке компилятора CS1704 для более подробной информации.

Чтобы решить эту проблему, вы можете попытаться предоставить им строгое имя. Если этот вариант не по вашему выбору, вы также можете попытаться удалить избыточную ссылку или переименовать одну из ссылок.

Вы можете проверить файл проекта, чтобы убедиться, что "PackageC" был импортирован (щелкните правой кнопкой мыши проект-> Выгрузить проект-> Изменить проект).

Answer 3

Это только что случилось со мной.
Проект является частью решения, а затем ссылается на другие проекты в решении. Ошибка заключалась в добавлении ссылки через абсолютный путь, т.е. \debug\output.dll (например) в диалоге добавления ссылки.
Это вызвало проблемы в последовательности компиляции, поскольку в других проектах в качестве ссылки на проект была добавлена ​​«output.dll», а конфигурация сборки была установлена ​​​​на «Выпуск». Следовательно, две разные ссылки на одну и ту же сборку во время последовательности сборки.

Чтобы решить, я просмотрел весь список проектов и удалил ссылку «Output.dll» и повторно добавил ее в качестве ссылки на проект. Это позволяет конфигурации выбрать соответствующую DLL на основе пути конфигурации. Любой проект, ссылающийся на другой проект в решении, следует добавлять через ссылку на проект, а не просматривать путь.

Answer 4

Что я могу сделать, чтобы отладить/исправить это?

В некоторых случаях со старым кодом (и отсутствием повторяющихся ссылок на сборки) эта ошибка возникает в одной версии Visual Studio, но не возникает в другой. Если у вас установлено несколько версий VS, запустите более новую, а затем в меню «Файл» откройте решение и соберите его. Если ошибка исчезнет, ​​у вас есть несколько вариантов сделать изменение постоянным:

Если вы чувствуете себя особенно смелым, вы можете вручную отредактировать файл решения (.sln), чтобы он всегда открывал проект в рабочей версии VS. (Чтобы найти номер версии для использования, создайте одноразовый проект и проверьте сгенерированный файл решения.) Например:

      VisualStudioVersion = 12.0.40629.0

может стать

      VisualStudioVersion = 15.0.28307.572

Однако вышеизложенное может быть несколько рискованным, поскольку форматы файлов могли измениться между версиями VS. Таким образом, другим подходом было бы воссоздание вашего проекта в рабочей версии VS и копирование кода.