error MSB3171: Problem generating manifest

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.

I'm getting this error compiling CSharp project, where:

CSharp project

A VS2008 C# project, that adds CppCli project as a reference

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

CppCli project

A VS2008 C++/CLI project that links to an external C++ static lib

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

Installed software (I understand VS2008+SP1 and .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

Some more details

- Generating an embedded manifest for CppCli, CSharp builds correctly.

- Line 2341 of Microsoft.Common.targets is a tag regarding GeneralApplicationManifest

- CppCli.intermediate.manifest points to Microsoft.VC90.DebugCRT.dll 9.0.30729.4148

- CppCli.manifest points to 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 shows 9.0.30729.4148 version

- Manually changing CppCli.manifest to point to 9.0.30729.4148, procmon traces show a NAME NOT FOUND when querying for C:\MyProject\Microsoft.VC90.DebugCRT.dll.manifest. Obviously, CRT manifest is not there. The point is that I don't find any traces querying for C:\Archivos de programa...\Microsoft.VC90.DebugCRT.dll.manifest, where the CRT manifest lives.

Questions

So I seem to have met two issues here: first, manifest generation. For that, I've found this link, although I don't know how useful it will be: http://www.eggheadcafe.com/software/aspnet/33380343/compiling-32bit-application-x86-in-vs2008-vc2008-on-vista-64bit----x64.aspx. It says you have to use a define in every compilation unit. Secondly, and most important to me now, how come changing the CppCli.manifest manually I still cannot build CSharp project.

Edit

I've moved the project to VS2010, using the tool wizard, and I still have the same problem.

Edit 2011/06/13

I'm going now for the "use an embedded manifest" option. The project builds, but when I try to execute the CppCli code, it says that I'm not runni开发者_运维知识库ng a valid Win32 application.

Edit 2011/06/15

CppCli project is linking to the following static libraries:

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

Dependencies are:

• CppCli uses YetAnother.

• YetAnother is a C++ project that uses curl and boost thread and date time.

• curl uses openssl.

I'm reading (http://marc.info/?l=boost-users&m=123425857320026) that statically linked boost libraries don't get on with CLR projects at all. So I remove those libboost lines, and use BOOST_ALL_DYN_LINK in CppCli, copy boost_thread-vc90-mt-gd-1_44.lib and boost_date_time-vc90-mt-gd-1_44.lib to YetAnother\Debug directory. Same error. The solution builds, but when I try to execute the CppCli code, it says that I'm not running a valid Win32 application.

Edit 2011/06/16

Giving up! I'm clearly being punished for taking Microsoft name in vain. Too many comments in the net saying boost static libs and CLR are not compatible. I'll change CppCli to not use CLR, and to communicate with CSharp via P/Invoke instead of Interop.

Edit 2011/06/17

All fine with P/Invoke.

---

I've had this issue before and it was because somehow a bunch of NGENed assemblies got corrupted and were no longer recognized as valid 64-bit or 32-bit assemblies. I first started removing the NGENed assemblies one by one, and the compilation would fail when attempting to load another dependency; it went all the way down to mscorlib, at which point I deleted all NGENed assemblies. Everything was fine after that, once they were re-NGENed.