Ошибка Windows Forms: «Требуется сборка со строгим именем» - PullRequest
Новая
       51

Ошибка Windows Forms: «Требуется сборка со строгим именем»

16 голосов
/ 14 ноября 2008

У меня есть проект Windows Forms (VS 2005, .net 2.0). В решении есть ссылки на 9 проектов. Все работает и прекрасно компилируется на одном из моих компьютеров. Когда я перемещаю его на второй компьютер, 8 из 9 проектов компилируются без проблем. Когда я пытаюсь скомпилировать 9-й проект (основной проект для приложения - создает файл .exe для выполнения приложения), я получаю следующую ошибку: 

'Error 3: A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)'

Местоположение файла для ошибки указано как «C: \ PATH-TO-APP \ LC».

Я проверил свойства проекта, и все проекты настроены на сборку в режиме отладки, ни один из них не должен быть подписан. В проекте, который терпит неудачу, единственная сборка, на которую он ссылается, но не входит ни в один из других проектов, это Microsoft.VisualBasic (сборка .net 2.0). Поэтому я не могу найти, какие идентификаторы, вызывающие эту ошибку (файл, указанный выше в сообщении об ошибке - «LC»), не существует.

Кто-нибудь знает, как я могу заставить проект принять все неподписанные сборки или определить, какая сборка является виновником?

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

Используемые сторонние сборки:

  • ComponentFactory.Krypton.Toolkit
  • ComponentFactory.Krypton.Navigator
  • VistaDB.NET20

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

До сих пор я пытался удалить файл suo, перестроить все, выгрузить и перезагрузить проекты из решения, удалить и прочитать ссылочные сборки. Ничего не сработало.

Ответы [ 8 ]

13 голосов
/ 27 марта 2017

Перейдите в свойства проектов и в левой навигационной панели / меню выберите Подписывание, если флажок «Подписать сборку» снят, снимите этот флажок. Это просто означает, что сборка со строгим именем ссылается на сборку со слабым именем. Затем CLR генерирует исключение FileLoadException

10 голосов
/ 25 февраля 2009

Я только что собрал его, выполнив следующее:

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

6 голосов
/ 01 июля 2016

Еще одна возможная причина:

(для отчаянных неисправников)

В окне Solution Explorer , если вы пройдете по списку ссылок и отметите каждое из них в окне Свойства , увидев свойство Сильное имя = Ложь , указывает на потенциальную проблему .

4 голосов
/ 23 декабря 2009

Я удалил файл лицензии из папки «Мои проекты» и заново собрал, он был успешно собран.

1 голос
/ 17 августа 2009

Я использовал много сторонних библиотек (MS Ent Lib) и решил переместить несколько библиотек DLL в «неиспользуемую» папку. Это дало мне ошибку в вопросе. Я полагаю, что одна из библиотек, на которую я ссылался, на самом деле ссылается на другую библиотеку, которая должна находиться рядом с ней (даже при том, что в вашем проекте нет необходимости ссылаться на dll).

После перемещения библиотек обратно все скомпилировано без этой ошибки.

1 голос
/ 14 ноября 2008

хорошо, не уверен, поможет ли это, но если у вас есть доступ к ildasm, изучите сторонние сборки и проверьте следующее: (Я обнаружил следующее прибегание к поиску сообщений об ошибках в сообщении об ошибке) Это из другого сообщения парней, так что игнорируйте имена, но ключ в том, что внутри манифеста строка должна читать «.publickeytoken», а не «.publickey» Ссылка на эту тему находится по адресу:

http://social.msdn.microsoft.com/Forums/en-US/clr/thread/56e13ab1-4c03-4571-92f1-759081bcc78b/ 

Public Key or Token: ab 1a 81 37 f9 79 0c 88

Loooks хорошо, верно? Эта последовательность действительно является маркером открытого ключа Reflex.dll.

Проблема может быть замечена, если мы используем графический интерфейс ildasm и нажимаем «манифест»: 

.assembly extern Reflex
{
.publickey = (2F 5A 20 3A 86 D3 5F 71 ) // /Z :.._q
.ver 1:0:0:0
}

Обратите внимание на строку .publickey.

Надо сказать .publickeytoken !!!

Проблема в том, что модуль Cecil при создании измененной сборки помещает маркер открытого ключа в поле открытого ключа (или забывает включить какой-либо флаг, который говорит, что это токен, а не полный открытый ключ. I не знаю подробностей).

Так что это составляет вероятную ошибку в Сесиле ... Я должен был вместо этого использовать вещь Гаэля .... :)

в любом случае, теперь я знаю, что ЕДИНСТВЕННАЯ проблема с оригинальным сценарием (до того, как я перешел в Сесил) заключалась в том, что он помещал ссылку на сборку без строгого имени (Reflex) внутри сборки со строгим именем (FXCOP) ,

Так что я исправил это сейчас и перезапустил свой оригинальный сценарий и ... альт! Это работает !!

1 голос
/ 14 ноября 2008

Проверьте раздел ссылок каждого проекта в обозревателе решений ... Найдите ссылки на сборки сторонних поставщиков, такие как Infragistics, Data Dynamics и т. Д., Которые могут быть не установлены на компьютере, на котором возникла проблема

0 голосов
/ 25 ноября 2008

Возможно, вам придется явно указать вашу целевую платформу и установить ее на x86. Может быть проблема с 64-битной сборкой.

Другое дело: вы запускаете VS от имени администратора? Есть проблемы с VS2005, когда он не работает с повышением прав в Vista, возможно, эта странная ошибка компиляции - одна из них.

...