Ich habe ein auf Windows 2000 mit VC++.NET 2002 SP1 entwickeltes Programm auf einen Rechner mit XP Home 2002 SP 2 verschoben (dort das gleiche VC++ und Microsoft Net-Framework 1.0).
Dort lässt sich das Prgramm nicht mehr starten, weder durch Doppelklick auf das exe, noch durch Starten im Debug- oder Release-Modus innerhalb VC++.

Das Programm ist eine dialogbasierte MFC-Anwendung und "use mfc in a static library" ist eingeschaltet. Was fehlt denn jetzt noch?

Grüße OS

Was heisst, nicht mehr starten? Kommt eine Fehlermeldung, oder beendet sich das Programm direkt?

Wenn Fehlermeldung, dann bitte angeben.

Wenn sich das Programm direkt beendet (ohne Meldung), dann ist eine mögliche Ursache ein ActiveX oder eine erweiterte Control, die auf dem Zielsystem nicht installiert/registriert ist.

Wenn du im Debugger startest, muss doch irgendwas passieren? Da sollte auch im Debug-Output etwas stehen (Access Violation, Error, irgendwas)

Ok, hier weitere Infos.

1) Fehlermeldung bei Doppelklick aufs EXE:
"Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist. Zur Problembehandlung sollten Sie die Anwendung neu installieren."

2) Aufruf innerhalb VC++,NET 2002 Debug oder Release Konfiguration:
"Das Debuggen konnte nicht gestartet werden". Dann der gleiche Text wie bei 1)

Es handelt sich um eine mit dem Assistenten erzeugte dialogbasierte MFC-Anwendung mit einer einzigen Dialogbox und ein paar Event-Handlern für Knopfdrücke. Nicht einmal der erste Breakpoint in InitInstance() wird erreicht.

Ich habe schon im Internet gesucht und kann folgendes gewährleisten:
- Ich bin Mitglied der Debugger-Gruppe. Andere Programme laufen ja.
- Es läuft der "Debug Machine Manager" als Dienst.
- Ich habe die MFC statisch gelinkt.
- DirektX-Unterstützung wurde bei Projekterstellung nicht eingeschaltet.
- Einzige Zusatz-Lib ist die wsock32.lib.

Erzeuge ich ein neues leeres MFC-Projekt, so gibt es diese Probleme nicht. Vielleicht werde ich meine paar Zeilen Code in das neue Projekt hinein kopieren. Trotzdem wäre interessant, warum sich so ein seltsames Verhalten einschleicht.

Stimmt, das wäre es. So was simples wie Komplett neu erstellen hast du vermutlich schon ausprobiert?

Sonst würde mir nur noch einfallen, dass da irgendwelche Pfade fest reinkodiert sind, oder es eben doch unterschiedliche MFC-Bibliotheken sind?
Oder die einzelnen Projekt-Einstellungen vergleichen. Es muss ja an sich einen Unterschied geben.

Hi

gleiches Problem hatte ich auch,
gleiches Studio.. gleiches Verhalten wollte von 2000 auf XP ... und es ging nicht

ich musste das unter XP nochma neu machen .. also Projekt mit gleichen namen erstellen ... speichern.. schließen.... Quellcode Dateien und Resourcen rein kopieren.. .. aber nicht die Projekt Datei ersetzen.... dann Projekt starten und die Ganten *.h und *.cpp Files einbinden. speichern ... neu öffnen.. dann sollten auch die Resourcen übernommen sein... dann kompilieren und wenn noch vorhanden kleinere fehlerchen beheben... ich hab dann ma aus fun die EXE von 2000 und XP binär verglichen .... Resultat .. Exakte Übereinstimmung ... Bit für Bit ... Ursache : KEINE AHNUNG .. aber es Lief dann sowohl auf XP als auch unter 2000 .. und ich kann es heute noch unter 2000 weiterentwickeln .. und es läuft auch wieder auf XP .. wie gesagt ... probieren... so ne richtige Ursache konnten die Supporter von MS auch nicht nennen.

Durch das Neuerzeugen und Copy-and-Paste des Programm-Codes bin ich nun auch am Ziel.
Gut, dass es kein größeres Programm war. Auch ich kann in den Project-Settings oder sonstwo keine Unterschiede entdecken. Ich setze den Beitrag mal auf "erledigt".

Gleiches Problem mit einer exe gehabt und behoben. Bei mir war die Einstellung C/C++->Code Generation falsch (Multi-threaded DLL). Nach der Anpassung (Multi-threaded /MT) geht's.

Hallo,
das Problem ist, dass das Programm bestimmte DLL's nicht findet. Ausführen von vcredist.exe auf dem Zielrechner sollte genügen.

Mfg

langer

- Auf Multithreaded MT stand das Projekt bereits.
- Wo finde ich denn vcredist? Im Visual C++ Programmverzeichnis bei mir nicht.

Grüße OS

Hallo,
vcredist installiert die norwendigen redistributablen DLL's, die von der MFC benötigt werden. Es gibt eine 32-Bit-Version (vcredist_x86) und eine 64-Bit-Version (vcredist_x64). Beide befinden sich im Ordner
Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages

Mfg

langer

Ich habe ja Visual Studio 7. Da gibts solche Verzeichnisse nicht.
Wäre auch unschön, wenn Benutzer ohne VS erst "vcredist" ausführen müssten für eine winzige Standard-Anwendung wie meine.

Hmm,

dann mußt du mal bei Microsoft schauen. Es ist so, dass ab XP die MFC-typischen DLL's nicht mehr mitgeliefert werden. Bis VC 6 und Win98 war das der Fall. Deshalb gibt es eben die Redistributabels, um die benötigten DLL's zu installieren. Leider gibt die Fehlermeldung ja nicht viel her, welche DLL's o. ä. fehlen. Ich habe nur immer gefunden, dass mit dem Ausführen von vcredist die Anwendungen liefen.

Mfg

langer

Och nö, keine Lust. Ich habs ja schon längst anders gelöst (siehe #6).

Gruß OS

Hi,

vcredist_x86 hilft bei einer Release-Version. Ich will aber remote debuggen und die Debug-Version will nicht laufen. Ist das nicht ätzend?

Ah, die Frage ist endlich mal schön einfach: Ja, es ist ätzend!
Vielleicht gibts von den redist_x86 auch Debug-Versionen?

Grüße OS