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

Ответ 1

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

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

NuGet

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

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

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

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

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

Ответ 2

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

Меню: Проект | 'Название проекта' Свойства... | Вкладка "Безопасность" | Установите флажок "Включить параметры безопасности ClickOnce".

Ответ 3

Смотрите ответ.

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

Удаление DLL (где произошла ошибка) и повторное построение решения устранили мою проблему. Благодаря

Ответ 9

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

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

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

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

Рекомендация Life Pro:

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

Разгрузка и перезагрузка проблемного проекта разрешила это для меня.

Ответ 13

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

Сборка → Реконструкция решения

Ответ 14

Правильно ли подписан ваш сборник?

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

Ответ 15

Теперь Вот другой подход к проблеме:

• Щелкните правой кнопкой мыши по проекту и выберите вариант "Выгрузить проект". Вы заметите, что проект становится недоступным.

• Щелкните правой кнопкой мыши на недоступном проекте и выберите "Изменить".

• Прокрутите вниз до '<ItemGroup> ', который содержит все теги ресурса.

• Теперь перейдите к ссылке, которая была отображена в списке ошибок, вы заметите, что она использует один тег (т.е. < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).

• Измените это, чтобы выглядеть следующим образом:

.

<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
    < Private > True < / Private >
    < HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >

• Сохраните изменения. Щелкните правой кнопкой мыши на недоступном проекте и выберите опцию "Обновить проект", затем создайте.

Ответ 16

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

Ответ 17

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

Ответ 18

Если ваш основной проект использует некоторые проекты библиотек и ссылается на них, вы можете вызвать эту проблему, если ссылка на проект в DLL файл сборщика вместо проекта библиотеки, когда вы что-то измените в своем проекте библиотеки (например: переименовать класс).

Вы можете проверить все ссылки на ваш основной проект по представлению в окне "Обозреватель объектов" (меню "Вид" → "Обозреватель объектов" ). Ссылка на файл dll всегда имеет номер версии. Пример: TestLib [1.0.0.0]

Решение: удалите текущую ссылку вашего основного проекта в проект библиотеки и снова добавьте ссылку на этот проект библиотеки.

Ответ 19

Я пошел публиковать файлы приложения и обнаружил, что dll, выдавшая ошибку, изменил ее на "Включить" из "Включить (Авто)". Теперь я могу опубликовать.

Ответ 20

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

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

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

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

Ответ 21

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

Ответ 22

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

Ответ 23

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

Ответ 24

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

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

Ответ 25

Я столкнулся с этой проблемой после переноса надстройки Excel из packages.config в PackageReference. Кажется, связано с этой проблемой.

Следующее работает как грубый обходной путь, если вы не используете ClickOnce (он пропустит всю информацию о зависимостях из файла .manifest):

1. Выгрузить проект, отредактировать .csproj

2. Найдите раздел, похожий на этот:

   <!-- Include additional build rules for an Office application add-in. -->
   <Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />
   

3. Отредактируйте переименованную копию упомянутого файла .targets (в моем случае файл разрешен в C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets и я сделали копию Microsoft.VisualStudio.Tools.Office_FIX.targets в той же папке - не проверял, работает ли она из другой папки).

4. Найдите элемент GenerateApplicationManifest и измените его атрибут Dependencies="@(DependenciesForGam)" на Dependencies="".

5. Измените раздел, найденный в 2., чтобы ссылаться на ваш отредактированный файл .targets.

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

Ответ 26

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

Ответ 27

Попробуйте использовать пакет обновления -reinstall -ignoredependencies