Ошибка Windows Forms: "Требуется сильно названная сборка"

У меня есть проект форм Windows (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" - не существует.

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

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

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

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

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

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

Ответ 1

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

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

Ответ 2

Я удалил файл лицензии из My Project Folder и снова заново построил его, он был успешно создан.

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

ok, не уверен, поможет ли это, но если у вас есть доступ к ildasm, просмотрите три сборки третьей стороны и проверьте следующее: (я обнаружил следующую ошибку в вашей ошибке: msg) имена, но ключ заключается в том, что внутри манифеста строка должна читать ".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 gui и нажимаем на "manifest":

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

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

Он должен сказать .publickeytoken!!!

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

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

В любом случае, теперь я знаю, что единственная проблема с исходным script (до того, как я переехала в Сесил) заключалась в том, что она помещала ссылку на сборку с неименованным именем (Reflex) внутри сильно названной сборки ( FXCop).

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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