Seite an Seite Wahnsinn - läuft Binärdateien auf demselben Computer

Question

Hier ist meine Konfiguration:

• Computer A - Windows 7, MS Visual Studio 2005 gepatcht für Win7 Kompatibilität (8.0.50727.867)
• Computer B - Fenster XP SP2, MS Visual Studio 2005 installiert (8.0.50727.42)

Mein Projekt hat einige externen Abhängigkeiten (vorkompilierte DLLs - entweder bauen auf A oder aus dem Internet heruntergeladen), ein paar DLLs aus Quellen gebaut und O ne ausführbare Datei. Ich entwickle mich am meisten auf A und alles ist in Ordnung. Irgendwann versuche ich mein Projekt auf dem Computer B aufzubauen, die vorgefertigten DLLs in den Ausgabeordner zu kopieren. Alles baut in Ordnung, aber versucht, meine Anwendung ich

bekommen zu starten

Die Anwendung konnte nicht richtig initialisiert (0xc0150002) ....

Das Ereignisprotokoll enthält zwei davon:

Abhängige Assembly Microsoft.VC80.CRT konnte nicht gefunden werden und Letzter Fehler war Die referenzierte Assembly ist nicht auf Ihrem System installiert.

plus etwas amüsanter

Aktivierungskontext generieren fehlgeschlagen für some.dll. Referenzfehlermeldung: Der Vorgang wurde erfolgreich abgeschlossen.

An diesem Punkt Ich versuche, mein Google-Fu, aber vergeblich - praktisch alle Hits sind über Binärdateien auf Maschinen ohne Visual Studio installiert ausgeführt wird. In meinem Fall können die ausführbaren Dateien jedoch nicht auf dem Computer ausgeführt werden, auf dem sie erstellt werden.

Nächster Schritt war Dependency Walker zu versuchen, und es verwirrt mich noch mehr - meine DLLs aus Quellen auf dem gleichen Feld gebaut nicht MSVCR80.DLL und MSVCP80.DLL finden, aber die ausführbare Datei in Bezug auf zu sein in Ordnung scheint, diese beiden DLLs, dh wenn ich öffnen die ausführbare Datei mit Abhängigkeit Walker zeigt, dass die MSVC?80.DLL s gefunden werden kann, aber wenn ich eine meiner DLLs öffne, heißt es, dass sie nicht können. Das ist, wo ich völlig aus Ideen, was zu tun ist, ich frage Sie, lieber stackoverflow :)

Ich gebe zu, ich bin ein bisschen verschwommen auf der ganzen Seite-an-Seite-Sache, so allgemein zu dem Thema lesen wird auch geschätzt werden.

Answer 1

Ihre Frage hat die Antwort auf Ihr Problem: Computer A VC-Laufzeit der Version 8.0.50727.867 und Computer B hat nur Version 8.0.50727.42 hat.

Sie haben Ihre Bibliotheken auf Computer A erstellt und hängen von der Version 867 der VC-Laufzeit ab. (Diese finden Sie im Manifest, das in die Bibliotheken eingebettet ist.) Wenn Sie sie auf Computer B kopieren, benötigen diese Bibliotheken weiterhin die Version 867 der Laufzeitumgebung, aber Sie haben nur die Version 42.

Um die VC-Laufzeit-Assemblyabhängigkeiten aufzulösen, müssen Sie Ich muss VC Runtime Redistributables von Version 867 auf Computer B installieren. Ich rate Ihnen jedoch, Visual Studio auf Computer B zu aktualisieren, so dass Sie die gleiche Version auf beiden Computern haben. Installieren Sie Visual Studio 2005 SP1 auf beiden Computern und installieren Sie dann this security update to SP1. Nach der Installation des letzteren hängen Ihre Bibliotheken von der Version 8.0.50727.4053 ab.

Answer 2

ist es möglich, dass das Problem mit verschiedenen Versionen der CRT-Laufzeit auf beiden Computern installiert ist. Ist es möglich, all Ihre Module so zu erstellen, dass sie die statisch verknüpfte CRT-Laufzeit verwenden, um dies zu überprüfen?

Answer 3

zuerst würde ich, dass vorkompilierte DLLs überprüfen, indem Dummy-Projekt vorbereitet werden

Answer 4

ich vor kurzem hatte die gleiche Art von Fehler zu laden, wenn Projekte auf einer Maschine zu bauen und sie dann auf eine andere Maschine zu bewegen. Der größte Schuldige ist wahrscheinlich eine Debug-Konfiguration für eine der binären Komponenten.Das heißt, MSVC hat die ziemlich strenge Anforderung, dass alle DLLs/EXEs mit der gleichen Laufzeitbibliothek erstellt werden, debuggen oder releasen, andernfalls werden sie nicht zusammen funktionieren.

Wenn ich das geschehen hatte, neigen sie auch dazu, gut zu kompilieren, aber wenn Sie versuchen, sie auszuführen, erhalten Sie diese extrem kryptische Fehlermeldung.

Sie müssen sicherstellen, dass jedes Modul, das Sie zusammen bauen, die gleiche Konfiguration verwendet, also Debuggen oder Freigeben über die gesamte Build-Kette. Dieser Fehler führt wahrscheinlich auch zu Fehlübereinstimmungen in anderen Bibliotheken. Stellen Sie daher sicher, dass Ihr MSVC genau die gleiche Version auf den Computern ist, auf denen Sie gerade arbeiten.