Hi,
ich habe seit ein paar Wochen ein etwas merkwürdiges Problem. Obwohl ich alle DLLs von VS (2005) mitliefere, kann das Programm auf einem Nicht-Entwicklungsrechner nicht mehr gestartet werden. Ich erhalte dann immer die nette Fehlermeldung "Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren". Der Dependency Walker wird etwas genauer und verrät mir noch "Error: The Side-by-Side configuration information for "c:\xxx\TEST.EXE" contains errors."
Das Seltsame ist, dass dieses Problem erst seit einigen Wochen auftritt und es vorher problemlos funktionierte. Es kann auch nicht an den Projekteinstellungen meines VS Projekts liegen, da ich bei mir zuhause auf meinem Rechner das Problem nicht habe. (Beide Systeme laufen mit Qt 4.5.2, selbst kompiliert - mit dem Flag -no-qt3support, und dem der VS Integration 1.4.3)
Zugegebener Maßen lässt sich das Problem durch die Installation des Redist-Packs lösen, ich würde aber ganz gerne wie bisher die DLLs in meinem Programmverzeichnis mitliefern.
Ich habe jetzt schon recht viel ausprobiert, leider ohne Erfolg. Hat jemand eine Idee was genau mein Problem verursachen könnte?
Gruß Michael
P.S.: Wenn ich mir einfach ein normales Win32 Programm aus der VS Projektliste schnappe und kompiliere, funktioniert das ohne Weiteres...
[gelöst] Qt und VS 2005 (Problem mit den Redist DLLs)
[gelöst] Qt und VS 2005 (Problem mit den Redist DLLs)
Zuletzt geändert von Baz am 4. September 2009 16:12, insgesamt 1-mal geändert.
Nicht dass ich wüsste... ich habe einfach ein normales GUI-Projekt erstellt und kompiliert, also komplett ohne irgendwelche zusätzlichen Abhängigkeiten. Für die exe wird ja nur ein intermediate manifest erzeugt, sonst wüsste ich nicht, welches fehlen könnte.
Ganz abgesehen davon, wenn ich das gleiche projekt auf meinem Rechner zuhause kompiliere und einfach nur das exe File austausche, funktioniert es.
Ganz abgesehen davon, wenn ich das gleiche projekt auf meinem Rechner zuhause kompiliere und einfach nur das exe File austausche, funktioniert es.
Am besten die vier Dateien aus Deinem Entwickler-Verzeichnis "[InstallDir]\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT" in das Applikationsverzeichnis Deiner Applikation kopieren. Es sollten die Dateien "Microsoft.VC80.CRT.manifest", "msvcm80.dll", "msvcp80.dll" und "msvcr80.dll" sein.
Vor ein paar Wochen hat's ein Security-Update der ATL gegeben, das automatisch über Windows Update installiert wird. Das solltest du ggf. auf den Nichtentwicklungsrechnern nachziehen.
http://www.microsoft.com/technet/securi ... 9-035.mspx
http://www.microsoft.com/technet/securi ... 9-035.mspx
Das ist ja genau das was ich gemacht habe und wie ich es ganz gerne weiterhin machen wrüde... Aber wie gesagt, es geht nicht.Markus hat geschrieben:Am besten die vier Dateien aus Deinem Entwickler-Verzeichnis "[InstallDir]\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT" in das Applikationsverzeichnis Deiner Applikation kopieren. Es sollten die Dateien "Microsoft.VC80.CRT.manifest", "msvcm80.dll", "msvcp80.dll" und "msvcr80.dll" sein.
Werd ich mal ausprobieren, dankeDarkWotan hat geschrieben:Vor ein paar Wochen hat's ein Security-Update der ATL gegeben, das automatisch über Windows Update installiert wird. Das solltest du ggf. auf den Nichtentwicklungsrechnern nachziehen.
http://www.microsoft.com/technet/securi ... 9-035.mspx
Es gibt tatsächlich ein neues Redist Paket, allerdings ist mir gerade mal aufgefallen, dass ich nichtmal zuhause bei mir auf meinem Rechner ein Programm starten kann, das im Büro kompiliert wurde... Der einzige offensichtliche Unterschied, der Rechner im Büro hängt in ner Domäne, der zuhause nicht... Sind sogar beides Core2Duo.
Das Problem hatten wir hier in der Firma auch.
Nach dem Update mussten wir:
- Qt komplett neu compilieren, sonst stehen da auch die falschen Runtime Versionen drin.
- Plugins neu compilieren
- Eigene Binarys komplette neu compilieren.
Wenn nur ein einer Dll die falsche Runtime Version drin steht, und die ist auf dem Zielrechner nicht vorhanden, dann läuft das Programm auch nicht.
Auf dem Entwicklungsrechner hat man das Problem normalerweise nicht, da auf diesem alle möglichen Versionen der Runtimes irgendwo im Windows Verzeichnis rumliegen.
Nach dem Update mussten wir:
- Qt komplett neu compilieren, sonst stehen da auch die falschen Runtime Versionen drin.
- Plugins neu compilieren
- Eigene Binarys komplette neu compilieren.
Wenn nur ein einer Dll die falsche Runtime Version drin steht, und die ist auf dem Zielrechner nicht vorhanden, dann läuft das Programm auch nicht.
Auf dem Entwicklungsrechner hat man das Problem normalerweise nicht, da auf diesem alle möglichen Versionen der Runtimes irgendwo im Windows Verzeichnis rumliegen.
Haben nur das Security Update installiert, bzw. installieren lassen und danach dann compiliert.
In den Dlls / Exes gibt es einen Key:
name="Microsoft.VC80.CRT"
version="8.0.50727.4053" = neue Version
version="8.0.50727.762" = alte Version
Es kann aber auch sein, dass mehrere drin stehen, dann hat man ein Problem. Bei uns war das der Fall, weil wir unsere Dlls neu compiliert hatten, die von Qt allerdings nicht.
In den Dlls / Exes gibt es einen Key:
name="Microsoft.VC80.CRT"
version="8.0.50727.4053" = neue Version
version="8.0.50727.762" = alte Version
Es kann aber auch sein, dass mehrere drin stehen, dann hat man ein Problem. Bei uns war das der Fall, weil wir unsere Dlls neu compiliert hatten, die von Qt allerdings nicht.
