Discussion :

[shenron666]

Bonjour,

J'ai un problème qui me bloque depuis hier avec toutes les applications MFC développées sous vs2003
Ces dernières refusent totalement de s'éxécuter sur un pc où vs2005 n'est pas installé
J'ai accés à 2 PC avec XP fraichement installé où vs2005 est présent, l'application se lance sans broncher
Un autre PC sans vs2005, lui aussi avec XP fraichement installé, refuse de lancer l'application
Et le plus important, la machine de traitement avec XP pas frais qui est prévue pour faire tourner les programmes que je développe, même problème au lancement

dès que je double clic sur l'exe, windows me sort une erreur :

L'application n'a pas réussi à s'initialiser correctement (0xc0150002). Cliquez sur OK pour arrêter l'application.

J'ai tout essayé sans succès :
- installation des DLL runtime 8.0
- lecture du tuto de Farscape : http://farscape.developpez.com/tutor...on-vc6-vc2005/
- options de génération du projet avec bibliothèques MFC statique ou DLL partagée
- génération de code MT ou MD

je n'ai pas pu aller voir ce qui était proposé au lien donné dans ce post :
http://www.developpez.net/forums/sho...64&postcount=2
l'accès ne m'est pas autorisé

J'ai créé un projet de base pour tester et il me crée le même genre de problème sauf si je link statiquement les MFC
le problème c'est que j'ai un éxécutable et une dizaine de DLL, et lier statiquement les MFC aux DLL n'est pas accepté par visual

si quelqu'un a une idée, une piste à explorer, je désespère

[farscape]

salut,
si le projet de base cause aussi un probléme c'est que tu n'as pas distribuer correctement les DLL et la crt 8.0
http://c.developpez.com/faq/vc/?page=DLL#VC2005VCRedist
autre point: tu as un manifest pour le style xp dans tes applications ?

[shenron666]

Salut Farscape,

merci pour ta réponse mais j'ai malheureusement creusé sans succès de ces côtés là aussi
l'installation des DLL runtime 8.0 (vcredist_x86.exe) a été faite et n'a rien changé au problème
et les fichiers manifest semblent optionels puisqu'une simple application (un "hello world" MFC) fonctionne sans problème même sans les mettre à condition que les MFC soient liés statiquement sauf que c'est pas possible avec une DLL

en fait j'ai l'impression que windows charge les mauvaises DLL des MFC (les 7.1 de vs2003 ?)
la machine a pas mal de progs utilisant les MFC 7.1 et je ne peux recompiler ces progs (pas les sources )

j'ai contourné le problème (j'espère temporairement) en attendant une solution en transformant une partie de mes DLL (celles qui sont utilisées dans un petit projet) en bibliothèques statiques afin de pouvoir lier statiquement aux MFC
l'exe passe de 75Ko à 850Ko (petite appli)

sauf que l'exe du projet principal fait 1,5Mo en utilisant les MFC en DLL partagée, alors j'ose pas imaginer en lien statique
et puis les 2 projets (et quelques autres) ont des DLL en commun, c'est pourqsuoi j'aimerai bien retrouver la possibilité d'utiliser des bibliothèques dynamiques
j'ai un autre projet encore plus gros (environ 28 DLL) et ça me ferait mal de passer 2 jours à tout modifier en biblio statiques

bon j'y retourne, chaque idée est source de pistes à explorer
je vais voir si en virant les MFC 7.1 du dossier système de windows ça fait quelque chose (de bon )

[farscape]

Si tes DLL utilisent les MFC 7. Et que tu ne peux pas les reconstruire avec VC2005
Tu dois aussi distribuer les MFC 7.0
Quand je pense que MS annonçait la fin des problèmes pour les DLL avec VC2500, c’est pire qu’avant.
Un autre point dont il faut se méfier: le fait d’avoir des DLL en MFC 7.0 implique que celles-ci travaillent avec une CRT différente de ton application, alors attention, les libérations d’objets ou fermeture de fichiers doivent être faites dans le module (DLL ou programme) qui l’a initié sinon ça plantera…

[shenron666]

comment savoir si un exe et/ou une dll utilise bien les mfc80 ?
"dependency scanner" me permet de voir que l'exe comme la dll ne sont pas sensés faire appel aux mfc7x mais bien aux mfc8x

la machine sur laquelle l'exe recomplié sous vs2005 ne fonctionne pas ne pose aucun problème avec un exe compilé avec vs2003
si c'est un problème qui peut être lié à msvcrt.dll, que faire ?

l'application ne plante pas en pleine exécution mais dès le départ
la première chose que j'ai à l'écran c'est ce fichu message d'erreur

si tu veux, tu peux télécharger le zip à l'adresse suivante :
http://shenron.free.fr/AFFUtils.zip

tel quel, l'exe avec sa dll ne fonctionne que sur les machines où visual est installé

edit: j'ai essayé de virer les dll des mfc 71 mais ça ne change rien
j'ai aussi créé un projet en partant de rien, je peux utiliser une DLL normale mais à partir du moment où les MFC sont liées dynamiquement à l'exe ou à une DLL utilisée par l'exe ça ne va plus
:parti se pendre:

[farscape]

salut,
ton programme utilise des dépendances liées aux MFC 6.0 (visual 6.0).
MSVCRT.DLL et MSVCP60.DLL c'est du vc 6.0 ça ...
donc si les dll vc6.0 ne sont pas distribuées sur le poste non à jour ça ne fonctionne pas. (c'est peut être lz32.DLL qui en a besoin)
sur mon poste ça fonctionne très bien puisque j'ai visual 6.0 et Visual 2005 qui cohabite...

[shenron666]

normalement il n'y a rien qui fait référence à visual 6 dans mon prog
il a été développé avec visual 7 et je l'ai recompilé avec visual 8
lz32 je ne sait pas ce que c'est, première fois que j'en entend parler
et sur mon pc l'exe fonctionne alros que je n'ai pas visual 6

c'est à n'y rien comprendre

en plus, je viens de tester sur 2 autres machines
un XP où le problème est identique
un windows 2000 où il rale parceque MFC80.dll est introuvable, installation des redistribuables et l'application se lance
les 2 machines n'ont que visual 6 d'installé

serait-il possible que ce soit une mauvaise version de DLL ? (crt ou autre) ou une DLL corrompue ?

[farscape]

hé bien tu as la CRT liée a MSVCRT.DLL et c'est du vc6.0, pas .NET 2003 et ni VS 2005....
donc tu as bien un module qui utilise cette CRT .

[shenron666]

J'ai uploadé 2 exe compilés de 2 manières différentes ici :
http://shenron.free.fr/Test_MFC_80.zip

c'est exactement le même programme, j'ai simplement fait un nouveau projet de type application MFC, une simple boite de dialogue
je n'ai rien changé au code et je l'ai compilé 2 fois en modifiant dans les propriétés générales du projet de l'exe l'option "Utilisation des MFC"
- Test_MFC_80_dynamic : Utiliser les MFC dans une DLL partagée
- Test_MFC_80_static : Utiliser les MFC dans une ibliothèque statique

les 2 programmes fonctionnent sur :
- windows 2000 avec visual 6 et les redistribuables vs2005 installés
- windows XP avec visual 2005 installé (test sur 3 PC)

le dynamique ne se lance pas alors que le statique n'a pas de problème sur les autres PC, et sur un PC où les redistribuables 2005 ne sont pas installés il ne demande même pas la DLL, et installer les redistribuables ne change rien au message d'erreur

je sèche, à part faire des liaisons statiques je ne vois pas comment résoudre mon problème
à moins de retourner sous visual 2003....

edit :

hé bien tu as la CRT liée a MSVCRT.DLL et c'est du vc6.0, pas .NET 2003 et ni VS 2005....
donc tu as bien un module qui utilise cette CRT .

comment je peux changer cela ?

[shenron666]

Finalement, après avoir passé ma journée à chercher :
- désinstaller le SP2 XP
- (ré)installer le SP1a
- réinstaller le SP2
- installer les Framework .NET + Hotfix
- désinstaller / réinstaller les runtime vc80
- trifouiller la base de registre en vain

impossible de faire fonctionner le programme avec les MFC en DLL partagée sur 5 PC / 11 au total (il y a même un PC avec visual 2005 installé qui refusait de le faire tourner)

et comme les DLL ne sont pas prévues d'origine pour fonctionner en statiques, trop d'erreurs de lien apparaissent

j'ai trouvé la solution utilme : désinstallation complète de visual 2005
lundi je retourne sur visual 2003

donc si vous envisagez un jour de passer sur visual 2005 des programmes utilisant les MFC dans des DLL, je vous le déconseille fortement
et faites comme moi, prévoyez une sauvegarde de vos projets avant de les convertir vers une nouvelle version de visual
bon courage et surtout bonne chance