c# - bar - Почему я получаю «Assembly»*.dll, должен быть сильным, чтобы быть помеченным как обязательное условие ».




uwp title bar (18)

Я пытаюсь скомпилировать мой excel addin с помощью C # 4.0 и начал получать эту проблему при создании моего проекта в Visual Studio. Важно сказать, что раньше у меня не было этой проблемы. Что может случиться?


Было слишком много проектов в моем решении, чтобы пройти и индивидуально обновлять, поэтому я исправил это:

  • Щелкните правой кнопкой мыши мое решение и выберите «Управление пакетами NuGet для решения ...».
  • Переход на вкладку «Обновления»
  • Поиск поврежденного пакета и выбор обновления
  • Нажмите ОК, и это привело к обновлению всех экземпляров пакета

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

У меня было решение ClickOnce, выбрасывающее эту ошибку. Приложение Foo.dll на общую папку «Libs» и содержало ссылку на проект на Foo.dll . Хотя ни один из проектов в решении не ссылался на статическую копию Foo.dll в папке «Libs», некоторые ссылки в этой папке (то есть: у моего решения были ссылки на Libs\Bar.dll которые ссылался Foo.dll .) Поскольку приложение CO вытащило все зависимости от Libs а также их зависимости, обе копии вошли в проект. Это вызвало ошибку выше.

Я исправил проблему, переместив Libs\Foo.dll версию Libs\Foo.dll в подпапку Libs\Fix\Foo.dll . Это изменение заставило приложение ClickOnce использовать только версию проекта DLL, и ошибка исчезла.


Если вы изменили версию сборки или скопировали другую версию управляемой библиотеки, указанную в этой ошибке, вы также можете предварительно скомпилировать файлы, ссылающиеся на неправильную версию. «Исправьте все» (или удалив папки «bin» и «obj», как указано в предыдущем комментарии), следует исправить этот случай.


Если вы попробовали все другие ответы в этом вопросе, и вы:

  • В вашем решении есть несколько проектов
  • Имейте проект (Проект A), который ссылается на другой проект (Проект B), проект которого ссылается на пакет NuGet.
  • В Project A вы использовали Intellisense / ReSharper для ссылки на пакет NuGet, указанный в Project B (это может произойти, когда метод в Project B возвращает тип, предоставляемый пакетом NuGet, и этот метод используется в Project A)
  • обновил пакет NuGet через диспетчер пакетов NuGet (или CLI).

... у вас могут быть отдельные версии DLL пакетов NuGet в ссылках на проекты, так как ссылка, созданная Intellisense / ReSharper, будет «нормальной» ссылкой, а не ссылкой на NuGet, как ожидалось, поэтому процесс обновления NuGet выиграл ' t найти или обновить его!

Чтобы исправить это, удалите ссылку в Project A, затем используйте NuGet для ее установки и убедитесь, что пакеты NuGet во всех проектах одинаковы. (как объясняют в этом ответе )

Life Pro Совет:

Эта проблема может возникнуть, когда ReSharper / Intellisense предлагает добавить ссылку на ваш проект. Он может быть гораздо более сложным, чем приведенный выше пример, с несколькими переплетенными проектами и зависимостями, затрудняющими отслеживание. Если ссылка, предлагаемая ReSharper / Intellisense на самом деле из пакета NuGet, используйте NuGet для его установки.


Когда у меня возникла эта проблема, я исправил ее, отключив «Включить настройки безопасности ClickOnce».

Меню: Проект | 'Название проекта' Свойства ... | Вкладка «Безопасность» | «Включить настройки безопасности ClickOnce».


Когда это случилось со мной с WindowsAPICodePack после того, как я его обновил, я просто перестроил решение.

Build -> Реконструкция решения


Перейдите на страницу свойств проекта. Затем перейдите в раздел «Опубликовать», а затем «Файлы приложений». DLL, упомянутые в ошибке, будут отмечены там как предварительные условия. Измените их на «Включить»


Попробовав большинство решений здесь, я, наконец, просто добавил ссылку на проект из проекта click once, это изменило его на Include (Auto) из Include и, наконец, сработало.


См. Этот answer .

Перейдите на страницу публикации и нажмите «Файлы приложений». Оттуда вы должны увидеть список своих DLL. Убедитесь, что те, которые вас беспокоят, имеют статус публикации, обозначенный как «Включить», а не «Предварительное условие».


Соответствует ли ваша сборка правильной подписке?

Чтобы проверить это, нажмите Alt + Enter в своем проекте (или щелкните правой кнопкой мыши, затем «Свойства»). Перейдите в раздел «Подписание». Убедитесь, что установлен флажок «Подписать сборку», и выбран файл ключевого ключа с сильным именем, а флажок «Задержать только» не установлен .


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


У меня это было в решении с 6 проектами. Один из моих проектов касался названной сборки как ссылки на файл. Остальные все указывали на ссылку на проект.

Обычно я получаю другую ошибку в этих случаях.

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

надеюсь, что это поможет кому-то ...


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


Это вызывается при изменении версии DLL, на которую ссылаются. Вам нужно удалить все элементы или .dll в целевой сборке.


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


Я предполагаю, что вы не работаете с сильно названными сборками. У меня была эта ошибка, когда два проекта ссылаются на несколько разных версий одной и той же сборки, и более зависимый проект ссылается на эти проекты. Решение в моем случае состояло в том, чтобы удалить ключ и информацию о версии из имени сборки в файлах .csproj (это все равно не имеет значения), а затем выполнить чистую сборку.

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

NuGet

С NuGet легко попасть в эту ситуацию, если:

  1. Вы устанавливаете пакет в один проект в своем решении.
  2. Новая версия этого пакета развертывается в исходный пакет.
  3. Вы устанавливаете его в другой проект в том же решении.

Это приводит к двум проектам в вашем решении, ссылающимся на разные версии сборок этого пакета. Если один из них ссылается на другое и является приложением ClickOnce, вы увидите эту проблему.

Чтобы исправить это, выполните команду update-package [package name] в консоли диспетчера пакетов Nuget, чтобы довести все до уровня игрового поля, после чего проблема исчезнет.

Вы должны управлять пакетами NuGet на уровне решения, а не на уровне проекта, если нет веских причин. Управление пакетами уровня решения исключает возможность использования нескольких версий зависимостей. При использовании интерфейса управления, если вкладка « Консолидация » показывает, что 1 или несколько пакетов имеют несколько версий, подумайте об объединении их с одним.


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

Работает как шарм.


вам нужно подписать сборку с помощью ключа. Перейдите в свойства проекта под подписью вкладки:







.net-4.0