Сборка с таким же простым именем уже была импортирована ошибка без повторяющейся ссылки

Похоже, я не умею читать сегодня!
В проекте была ссылка на Interop и ссылка на COM, которая генерировала «такое же» взаимодействие. Так что их было двое, и я просто не очень хорошо искал. Я до сих пор не понимаю, почему это работало в других местах, но это исправило.

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

У меня была эта проблема, но в моем случае у меня была старая копия, помещенная в текущую папку для EXE, загружающего мой компонент, который был загружен вместе с текущим, который был загружен вручную из папки моих проектов. Удаление этой старой копии решило мою проблему.
Я использовал окно Отладка> Windows> Модули, чтобы увидеть, какие модули были загружены в то время, и это решило мою проблему.

В моем случае повторяющаяся запись была вызвана ссылкой на пакет NuGet и прямой ссылкой на файл той же сборки в папке пакетов. Я не уверен, как проект попал в это состояние, но выгрузка проекта и поиск в XML-файле неправильного имени сборки решили проблему для меня.

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

Для других, которые сталкиваются с тем же, что и я: при сборке через командную строку с использованием свойства AssemblyName он перезапишет все сборки, созданные всеми проектами решения - другими словами, вы получите (N -1) сборок с такими же именами, где N - это нет. из проектов - запускаемый (который обычно генерирует exe).

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

Из упомянутой выше ссылки в msdn :

Глобальные свойства - это свойства, которые устанавливаются с помощью переключателя / property в командной строке, или свойства, которые задаются интегрированной средой разработки (IDE) перед построением проекта. Эти глобальные свойства применяются ко всем проектам, созданным с использованием этого движка.

В моем конкретном случае, когда Jenkins является инструментом CI, я закончил тем, что добавил в конце пакетную команду Windows, чтобы переименовать .exe только в то, что я изначально планировал при передаче параметра AssemblyName.

В окне «Список ошибок» проект, вызвавший эту ошибку, был указан в столбце «Проект». Я обошел ошибку, выполнив следующие действия:

• Я выгрузил указанный проект (щелкните правой кнопкой мыши => Выгрузить проект)
• Открыл XML для редактирования (щелкните правой кнопкой мыши выгруженный проект => Изменить {ProjectName.csproj}).
• Искал оскорбительный .dll и заметил, что он несколько раз указан в XML.
• Удален весь тег ссылки, связанный с ошибочной dll, и сделал это для каждой копии ссылки, кроме первой в списке.

Причина, по которой он был указан несколько раз, заключалась в том, что несколько библиотек, на которые есть ссылки, использовали эту dll. Само по себе это не должно быть проблемой, поэтому я не уверен, из-за чего эта ошибка внезапно появилась у меня. Я обновлю этот ответ, если выясню это.

Попробуйте вместо этого: удалите Interop.xx.dll из справочного раздела в обозревателе решений и перестройте проект.

Для тех, кто разрабатывает проекты UWP, в которых есть ссылки на проекты, в частности, Microsoft.Windows.SDK .Contracts nuget (или другие зависимости, которые на него ссылаются), это распространенная ошибка, когда версия контрактов SDK нацелена на другую версию среды выполнения, отличную от того, как настроен ваш проект.

Например, при настройке на Windows 10 версии 1903:

Любые зависимости или ссылочные проекты должны быть нацелены на одну и ту же версию среды выполнения или, по крайней мере, поддерживать ее.

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

Несмотря на то, что этот пакет для контрактов SDK имеет стабильное обновление, он несовместим с моей основной конфигурацией проекта, Nuget не знает об этом, поэтому разрешает обновление.

Этот пакет специально разработан для предоставления библиотек DLL Windows для типов проектов, которые НЕ поддерживают таргетинг на платформу Windows, он копирует те же библиотеки DLL, которые включены в конфигурацию таргетинга UWP. При установке более поздних версий пакета ссылки из вспомогательного проекта будут включены в выходные данные вместе с теми, которые предоставлены из-за ориентации на платформу, что в конечном итоге приведет к ошибке OP.

Существуют аналогичные SDK и пакеты таргетинга для среды выполнения устройств Windows IoT, эта информация должна помочь вам выявить и решить эти проблемы, если вы застряли на этом вопросе, как это часто делает моя команда :)