ошибка MSB3171: проблема при создании манифеста - PullRequest
9 голосов
/ 07 июня 2011

C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2341,9): error MSB3171: Problem generating manifest. Could not load file or assembly '...CppCli.dll.manifest' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Я получаю эту ошибку при компиляции проекта CSharp, где:

CSharp project

Проект VS2008 C #, который добавляет проект CppCli в качестве ссылки

Output type, Windows application
Platform target, Any CPU
I've also tried with Platform target, x86

Проект CppCli

Проект VS2008 C ++ / CLI, который ссылается на внешнюю статическую библиотеку C ++

Targeted framework .NET Framework 3.5
Configuration type, Dynamic Library (.dll)
Configuration properties, Common Language Runtime support, /clr
Manifest tool, Embed manifest, No

Установленное программное обеспечение (я понимаю VS2008 + SP1 и .NET3.5 + SP1)

Microsoft Visual C++ 2005 Redistributable KB2467175
Microsoft Visual C++ 2008 Redistributable KB2467174 x86 9.0.30729.5570
Microsoft Visual C++ 2008 Redistributable x86 9.0.21022
Microsoft Visual C++ 2008 Redistributable x86 9.0.30729.4974

Некоторые подробности
- Генерация встроенного манифеста для CppCli, CSharp строит правильно.
- Строка 2341 Microsoft.Common.targets является тегом, относящимся к GeneralApplicationManifest
- CppCli.intermediate.manifest указывает на Microsoft.VC90.DebugCRT.dll 9.0.30729.4148
- CppCli.manifest указывает на 9.0.21022.8
- C: \ Archivos de programa \ Microsoft Visual Studio 9.0 \ VC \ redist \ Debug_NonRedist \ x86 \ Microsoft.VC90.DebugCRT \ Microsoft.VC90.DebugCRT.manifest показывает версию 9.0.30729.4148
- При ручном изменении CppCli.manifest на 9.0.30729.4148 трассировки procmon показывают ИМЯ, НЕ НАЙДЕННОЕ при запросе C: \ MyProject \ Microsoft.VC90.DebugCRT.dll.manifest. Очевидно, что ЭЛТ-манифест не существует. Дело в том, что я не нашел никаких следов, запрашивающих C: \ Archivos de programa ... \ Microsoft.VC90.DebugCRT.dll.manifest, где живет манифест CRT.

Вопросы
Таким образом, я, кажется, столкнулся с двумя проблемами здесь: во-первых, манифестное поколение. Для этого я нашел эту ссылку, хотя я не знаю, насколько она будет полезна: http://www.eggheadcafe.com/software/aspnet/33380343/compiling-32bit-application-x86-in-vs2008-vc2008-on-vista-64bit----x64.aspx. В ней говорится, что вы должны использовать определение в каждом модуле компиляции. Во-вторых, и самое важное для меня сейчас, почему я могу изменить CppCli.manifest вручную, но я до сих пор не могу собрать проект CSharp.

Редактировать
Я переместил проект на VS2010, используя мастер инструментов, и у меня все еще остается та же проблема.

Изменить 2011/06/13
Сейчас я собираюсь использовать опцию «использовать встроенный манифест». Проект компилируется, но когда я пытаюсь выполнить код CppCli, он говорит, что я не работаю с приложением Win32.

Изменить 2011/06/15
Проект CppCli ссылается на следующие статические библиотеки:

YetAnother.lib
libcurl.lib
libboost_system-vc90-mt-gd-1_44.lib
libboost_thread-vc90-mt-gd-1_44.lib
libboost_filesystem-vc90-mt-gd-1_44.lib
libeay32MDd.lib
ssleay32MDd.lib
shlwapi.lib
ws2_32.lib
winmm.lib
wldap32.lib
winhttp.lib

Зависимости:

  • CppCli использует YetAnother.
  • YetAnother - это проект на C ++, использующий потоки curl и boost и дату и время.
  • curl использует openssl.

Я читаю (http://marc.info/?l=boost-users&m=123425857320026), что статически связанные библиотеки Boost вообще не включаются в проекты CLR. Поэтому я удаляю эти libboost строки и использую BOOST_ALL_DYN_LINK в CppCli, копирую boost_thread-vc90-mt-gd-1_44.lib и boost_date_time-vc90-mt-gd-1_44.lib в каталог YetAnother \ Debug. Та же ошибка. Решение строится, но когда я пытаюсь выполнить код CppCli, он говорит, что у меня не работает допустимое приложение Win32.

Редактировать 2011/06/16
Сдаваться! Я явно наказан за то, что взял имя Microsoft напрасно. Слишком много комментариев в сети, говорящих о повышении статических библиотек и CLR не совместимы. Я поменяю CppCli так, чтобы он не использовал CLR, и для связи с CSharp через P / Invoke вместо Interop.

Изменить 2011/06/17
Все в порядке с P / Invoke.

1 Ответ

1 голос
/ 22 июня 2011

У меня была эта проблема раньше, и это было потому, что как-то куча сборок NGENed была повреждена и больше не распознавалась как действительные 64-битные или 32-битные сборки.Сначала я начал удалять сборки NGENed одну за другой, и компиляция не удалась при попытке загрузить другую зависимость;он прошел весь путь до mscorlib, после чего я удалил все сборки NGENed.Все было хорошо после этого, как только они были повторно NENGEN.

...