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.
Ich erhalte diesen Fehler bei der Kompilierung von CSharp, wo:
CSharp-Projekt
Ein VS2008 C # -Projekt, das CppCli-Projekt als Referenz hinzufügt
%Vor%CppCli-Projekt
Ein VS2008 C ++ / CLI-Projekt, das mit einer externen statischen C ++ - Bibliothek verknüpft ist
%Vor%Installierte Software (Ich verstehe VS2008 + SP1 und .NET3.5 + SP1)
%Vor% Einige weitere Details
- Generiert ein eingebettetes Manifest für CppCli, erstellt CSharp korrekt.
- Zeile 2341 von Microsoft.Common.targets ist ein Tag bezüglich GeneralApplicationManifest
- CppCli.intermediate.manifest verweist auf Microsoft.VC90.DebugCRT.dll 9.0.30729.4148
- CppCli.manifest zeigt auf 9.0.21022.8
- C: \ Archives de programa \ Microsoft Visual Studio 9.0 \ VC \ redist \ Debug_NonRedist \ x86 \ Microsoft.VC90.DebugCRT \ Microsoft.VC90.DebugCRT.manifest zeigt 9.0.30729.4148 Version
- Wenn Sie CppCli.manifest manuell auf 9.0.30729.4148 setzen, wird in procmon traces ein NAME NICHT GEFUNDEN angezeigt, wenn nach C: \ MyProject \ Microsoft.VC90.DebugCRT.dll.manifest abgefragt wird. Offensichtlich ist CRT Manifest nicht da. Der Punkt ist, dass ich keine Spuren finde, die nach C: \ Archivos de programa ... \ Microsoft.VC90.DebugCRT.dll.manifest fragen, wo das CRT-Manifest lebt.
Fragen
So scheint es, als hätte ich hier zwei Dinge getroffen: erstens, manifeste Generation. Dafür habe ich diesen Link gefunden, obwohl ich nicht weiß, wie nützlich es sein wird: Ссылка . Es besagt, dass Sie eine Definition in jeder Kompilierungseinheit verwenden müssen. Zweitens, und das Wichtigste für mich, wie kann ich das CppCli.manifest manuell ändern, kann ich CSharp Projekt immer noch nicht erstellen.
Bearbeiten
Ich habe das Projekt mit dem Tool-Assistenten nach VS2010 verschoben und habe immer noch das gleiche Problem.
Bearbeiten 2011/06/13
Ich gehe jetzt für die Option "embedded Manifest verwenden". Das Projekt wird erstellt, aber wenn ich versuche, den CppCli-Code auszuführen, heißt es, dass ich keine gültige Win32-Anwendung ausführe.
Bearbeiten 15.06.2011
Das CppCli-Projekt verknüpft die folgenden statischen Bibliotheken:
Abhängigkeiten sind:
Ich lese (http://marc.info/?l=boost-users&m=123425857320026), dass statisch verknüpfte Boost-Bibliotheken mit CLR-Projekten überhaupt nicht zurecht kommen. Also entferne ich diese libboost -Zeilen und verwende BOOST_ALL_DYN_LINK in CppCli, kopiere boost_thread-vc90-mt-gd-1_44.lib und boost_date_time-vc90-mt-gd-1_44.lib in das YetAnother \ Debug-Verzeichnis. Derselbe Fehler. Die Lösung wird erstellt, aber wenn ich versuche, den CppCli-Code auszuführen, wird eine gültige Win32-Anwendung ausgeführt.
Bearbeiten 2011/06/16
Aufgeben! Ich werde bestraft, weil ich Microsoft vergebens genommen habe. Zu viele Kommentare im Netz, die statische Bibliotheken und CLR laden, sind nicht kompatibel. Ich werde CppCli ändern, um CLR nicht zu verwenden und mit CSharp über P / Invoke statt Interop zu kommunizieren.
Bearbeiten 2011/06/17
Alles in Ordnung mit P / Invoke.
Ich hatte dieses Problem zuvor und es war, weil ein Haufen von NGENed-Assemblys irgendwie beschädigt wurde und nicht mehr als gültige 64-Bit- oder 32-Bit-Assemblies erkannt wurden. Ich begann zuerst, die NGENed-Assembly nacheinander zu entfernen, und die Kompilierung würde fehlschlagen, wenn versucht wird, eine andere Abhängigkeit zu laden. es ging bis zu mscorlib hinunter, an diesem Punkt löschte ich alle NGENed-Assemblys. Danach war alles in Ordnung, sobald sie wieder genesen waren.
Tags und Links c# visual-studio-2010 visual-studio-2008 manifest c++-cli