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

266

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

Сергей Кучер
источник
72
Как быстро попытки, очистить оба binи objпапку вашего проекта, и вновь построить проект. Иногда это работает.
Джейсон Эванс
вы подписываете собрание?
Феличе Поллано
3
@ Джейсон, Очистка проекта и восстановление работали для меня. Я только недавно подписал сборки, и проект будет построен, но не будет публиковать.
Кратц
1
@Kratz - Рад, что этот совет сработал для вас :) Это немного похоже на исправление вашего компьютера, перезагрузив его!
Джейсон Эванс
Это случилось со мной, когда диспетчер конфигурации сбросил параметры сборки в нескольких моих проектах (то есть они не были настроены на сборку «Перестроить все»), после того, как версировали эти проекты и пересобрали ошибку, произойдет ошибка.
Алан

Ответы:

239

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

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

NuGet

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

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

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

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

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

Комплект
источник
7
Вот еще немного информации: social.msdn.microsoft.com/Forums/en/csharplanguage/thread/… . Также помогает очистка bin и obj и (если вы контролируете) установка версии сборки на одно и то же значение (например, оставление номера сборки на ноль).
Kit
3
Я немного добавил в конец вашего ответа, чтобы отразить мой сегодняшний опыт работы с NuGet и ту же ошибку. Надеюсь, это когда-нибудь поможет кому-то (возможно, даже мне через несколько месяцев!).
Нил Барнвелл
2
Эта ошибка постоянно появляется для меня и удаляет имя сборки из файла .csproj, затем очистка последовательно исправляет его для меня. Спасибо!
ScubaSteve
1
Вы можете захотеть увидеть этот ответ, если приведенный выше ответ не сработал, и вы думаете, что добавили ссылку NuGet в один из ваших проектов с помощью Intellisense / ReSharper.
Дэвид Мердок
Решение содержит 4 проекта. Один проект B - библиотека классов. На dll B ссылались в остальных трех. Два других проекта ( C и D ) исполняемые в настоящее время ссылаются в A . Так что я построил А и получил ту же проблему. Исправление было восстановить остальные два проекта первыми. И затем восстановление проекта . Исправлена ​​проблема.
Викрам Сингх Саини
268

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

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

Charlez
источник
2
У меня не работает в VS2012 (флажок автоматически проверяется во время публикации). Вместо этого я использовал этот ответ, так как DLL была необходима только для процесса сборки. stackoverflow.com/a/8123074/17713
Матиас Мейд
3
При использовании ClickOnce этот флажок автоматически устанавливается при каждой публикации приложения с помощью мастера публикации. См. Msdn.microsoft.com/en-us/library/1sfbfyk0.aspx для получения дополнительной информации.
Дэвид Мердок
8
У меня MSVS 2015, и я не вижу вкладку безопасности в свойствах проекта
zeta
70

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

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

Otiel
источник
2
Проект расширения exel не имеет кнопки «Файлы приложений». stackoverflow.com/questions/6378801/…
Сергей Кучер
@SergeyKucher: я этого не знал. Спасибо за обновление. Поскольку ваш вопрос не точен, он относится к надстройке Excel, я думаю, что мой ответ все еще действителен (у меня было то же сообщение об ошибке в проекте winforms, и я решил его таким образом).
Отиель
У меня есть проект winforms, который работал нормально, пока я не использовал мастер публикации, после чего я получил ошибки OP. Изменение статуса публикации устранило проблему. Спасибо
Кристиан
7
В моем случае эта проблема была решена путем изменения состояния публикации с INCLUDE (авто) на INCLUDE. В любом случае, ваш ответ помог не засунуть показанные значения. Большое спасибо
Хулио Нобре
22

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

Даниил
источник
13

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

Sogger
источник
1
Или просто «Чистое решение»
нарезано
«Rebuild All» сначала выполняет clean и эквивалентно «clean», а затем «build». Однако следует отметить, что иногда, когда файлы были скопированы или скопированы вручную с разными временными метками, функциональность 'clean' / 'rebuild' не устраняет проблему, и требуется вручную удалить папки 'bin' и 'obj'.
Sogger
Для этой проблемы, связанной с Excel, удаление папок bin / obj работало для меня, другие подходы - нет.
Уильям Мелани
6

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

Феличе Поллано
источник
6

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

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

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

Ник Готч
источник
6

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

  • Есть несколько проектов в вашем решении
  • Имейте проект (Проект 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 для его установки.

Дэвид Мердок
источник
Да, избегайте использования Resharper для добавления ссылок. Resharper возьмет справочную DLL из папки отладки (или выпуска, если вы находитесь в режиме выпуска). Это вызовет много проблем, особенно в огромных проектах.
Cepriego
5

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

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

Натан
источник
4

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

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

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

ChrisO
источник
4

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

Джимми
источник
4

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

FunctorSalad
источник
2
Чтобы добавить к этому, более мягкий способ решения проблемы - скопировать весь раздел <Target Name = "VisualStudioForApplicationsBuild"> из файла, расположенного в точке 3 (т.е. просто найдите файл, не копируйте и не переименовывайте его) , в файл. ** proj вашего собственного проекта и внесите те же изменения, что описаны в пункте 4. Это переопределит поведение только для вашего проекта и не повлияет на что-либо еще на вашем компьютере. Если в будущем обновлении VS появятся изменения в исходном файле, вам, возможно, придется повторить процесс.
Адам
3

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

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

Арсений Мурзенко
источник
Я не подписал * .dll, но раньше проблем с ним не было (раньше у меня не было ошибки компиляции). DLL, на которую ссылаются в одном из упомянутых проектов опубликованного, я нашел уродливое решение ссылаться на DLL непосредственно из опубликованного проекта. Скажите, пожалуйста, почему он работает сейчас? Или как я мог решить проблему другим способом? Спасибо
Сергей Кучер
1
@ user520535: ну, если вы раньше не подписывали библиотеку, вам следует. Это не единственный способ использования этой библиотеки подписанными сборками (подписанная сборка не может вызвать неназначенную сборку), но работа с не подписанными сборками также очень сложна, когда вы работаете с плагинами / add -ins. Теперь, почему это стало вызывать проблемы сейчас, а не раньше? Понятия не имею.
Арсений Мурзенко
@ user520535: если это помогло, вы можете принять или отозвать ответ.
Арсений Мурзенко
3

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

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

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

  • Прокрутите вниз до тега <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 >
  • Сохраните изменения, снова щелкните правой кнопкой мыши на недоступном проекте и выберите опцию «Перезагрузить проект», затем выполните сборку.
Технология
источник
3

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

Хоанг Ха
источник
2

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

Минни
источник
2

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

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

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

Хай Нгуен
источник
1

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

PatFromCanada
источник
1

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

Artexias
источник
0

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

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

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

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

Greg
источник
0

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

Люк Пуплетт
источник
0

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

Саймон Миллер
источник
0

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

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

FritsJ
источник
0

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

Стелла Оливейра
источник
0

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

SWIK
источник