Ошибка: сборка со строгим именем требуется

У меня есть проект форм 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. Криптон. Инструментарий
  • ComponentFactory. Криптон. Навигатор
  • VistaDB.NET20

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

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

18
задан abatishchev 13 September 2019 в 05:46
поделиться

4 ответа

Я просто заставил это создавать путем выполнения следующего:

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

10
ответ дан 30 November 2019 в 08:33
поделиться

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

1
ответ дан 30 November 2019 в 08:33
поделиться

хорошо, не уверенный, если это поможет, но если у Вас есть доступ к 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 gui и нажимаем на "декларацию":

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

Уведомление .publickey строка.

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

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

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

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

, Таким образом, я зафиксировал это теперь и повторно выполнил мой исходный сценарий и... альт! Это работает!!

1
ответ дан 30 November 2019 в 08:33
поделиться

Могло случиться так, что необходимо определить целевую платформу явно и установить ее на x86. Могла бы быть проблема со сборкой на 64 бита.

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

0
ответ дан 30 November 2019 в 08:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: