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

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

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

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

NuGet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы попробовали все остальные ответы в этом вопросе, и вы:

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

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

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

Life Pro Совет:

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

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

Построить -> Восстановить решение

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

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

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

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

Я столкнулся с этой проблемой после переноса надстройки 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обновляется версия файла, поставляемого с VS (или вы не получите обновления), но я надеюсь, что это будет исправлено в ближайшее время ...

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

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

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

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

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

• Прокрутите вниз до тега <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 >

• Сохраните изменения, снова щелкните правой кнопкой мыши на недоступном проекте и выберите опцию «Перезагрузить проект», затем выполните сборку.

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

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

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

Вы можете проверить все ссылки на ваш основной проект, просмотрев в окне Object Browser (меню View-> Object Browser). Ссылка на файл DLL всегда имеет номер версии. Пример: TestLib [1.0.0.0]

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

Попробовав большинство решений здесь, я наконец-то просто добавил ссылку на проект из проекта «щелкни один раз», изменив его на «Включить» (Авто) из «Включить», и он наконец заработал.

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

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

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

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

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

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

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

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

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

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

Просто перейдите в «Публикация» -> «Файл приложения» -> и измените статус публикации dll с обязательным условием включения! Это сработало для меня!