Version imprimable
Mes chers amis,
Je me plantais définitivement quelque part : Je n'observais pas les dépendances du bon fichier (hahahaha).
Je vous remercie pour cet apport en connaissances considérable. Ce n'est qu'un premier pas dans le déploiement de mon applicatif, je reviendrais surement avec des tas de nouvelles questions.
Merci encore
Question facultative :
C'est normal qu'en lancant mon .exe sur un autre PC, la CLI qui s'ouvre ne se referme pas automatiquement?
Je dirais que non: Tous les programmes Win32 console ont normalement leur console qui se ferme automatiquement à la fin du programme. Seuls les programmes DOS 16 bits pouvaient avoir la console qui reste affichée, et encore, seulement sous Win9x il me semble.
Je trouve cela étrange aussi. Surtout que cela va surement poser problème a chaque fois que je vais appeler mon programme à partir de l'IHM, car la tâche est surement considéré comme inachevée.
Donc si quelqu'un a déjà rencontré ce problème, je serais ravi d'avoir un avis.
(Sinon comment buildé une version release d'un programme qui exploite une DLL particulière. Etant donné que normalement le .dll est mis la ou on aura notre .exe? Parceque là, pour un des programme, il me lance 9 erreurs dues à des appels de fonction d'une DLL quand je veux build le release)
Es-tu sûr que la dépendance à la DLL est bien réglée dans la version Release du projet ? Si tu ne l'as réglée qu'en Debug, c'est normal que ça échoue...
PS: Si tu lances le programme depuis Visual, c'est normal que la console reste affichée: C'est une feature de Visual (qui manque à Dev-C++).
Comment faire pour régler la dépendance en release? (Je suis un pure Noob du déploiement - Stage de fin d'étude =>connaissances scolaire, et on ne m'as jamais fait déployer d'appli (je ferai d'ailleurs savoir a mon école que c'était une erreur :))
Sinon, l'autre pc n'a pas visual, je lance le programme en double cliquant sur le .exe généré par le release
Tu règles la dépendance en Release de la même façon que tu l'as réglée en Debug...
Simplement, tu le fais aussi en Release, quoi...
J'avais le meme probleme pour une appli developpée avec wxWidget. Les dll à rajouter sont dans un sous dossier de l'installation visual (il s'appel "redist" je crois, pour redistribuable). En gros, il manquait : trois dll pour les mfc (mfc80.dll et companie..), 3 dll pour la crt (msvcp80.dll...) avec les deux fichiers .manifest qui vont bien : Microsoft.VC80.CRT.manifest et Microsoft.VC80.MFC.manifest. Je precise que je compilais en multithread dll
Ok, je ne savais pas que ca modifiait les liens de passer de debug à release. J'ai bien installé vcredist sur mon autre pc, il semblerait que tout fonctionne, mais je vais faire des séries de tests pour m'en assurer. Je reposterais peut etre quelque chose plus tard :)
En tout cas merci à vous tous pour l'aide apportée!
Nom de Dieu!
Un de mes programmes est bel et bien en Release, mais il continue d'etre dépendant des bibliothèques ***d.dll...
Any ideas?
Je parie qu'il dépend d'une bibliothèque statique qui elle, est compilée en version Debug...
Ha ha
J'avais encore fais une erreur d'étourderie dans mes parametres de configuration, effectivement.
Par contre, le problème redouté arriva. Comme j'avais dit précédemment, le lancement d'un programme vc++ sur un autre PC ne ferme pas automatiquement la CLI, bizarrement.
Et bien cela cause bel et bien problème au final, parceque les fichiers exploités ne sont jamais refermés et ne peuvent être exploités par d'autres appli.
Sauriez vous d'ou peut venir le problème de la CLI qui reste ouvertes?
Es-tu sûr que ce n'est pas tout simplement le programme qui ne quitte pas ?
Si les fichiers sont "toujours ouverts", ça y ressemble... Et ça veut aussi dire que tu es un programmeur sale qui compte sur la fin d'un process pour fermer les fichiers...
Ha ha, un programmeur sale...
Non non, je suis un noob du déploiement, maisje me débrouille en codage et suis rigoureux lorsqu'il s'agit de traiter des fichiers ou de l'allocation dynamique.
Non il faut savoir que le programme que j'ai développer fonctionne très bien sur mon poste, mais dans l'optique d'une exploitation par d'autres personnes je dois le publier.
Les problèmes dont je parle n'interviennent que sur un autre poste que le miens. Je ne pense donc pas qu'il soit réellement dus au codage mais plutot, à des options ou des paramètres que je ne savais pas qu'il fallait prendre en compte ou configurer.
Eureka, c'est une question d'adresse relative
Merci encore de supporter mes borborygmes mentaux et de m'aider à y mettre fin
Il faut que tu scrutes toutes les options du projet en question, et vérifier qu'elles ne contiennent rien lié de près ou de loin à du débogage.
Le mieux serait de refaire un nouveau projet avec les sources actuelles.
Ouai j'aurais carrément du faire ca, mais j'avais plus trop le temps. Au final j'ai trouvé les sources d'erreurs, grace a votre soutient, et je vous en suis très reconnaissant.
L'important est que je tire des leçons de mon premier vrai projet.
Moi j'essaye de faire Qt creator en version portable, j'ai bien mit les dll et ceux vu dans depends directement depuis l'exe mais rien à faire que ce soit depuis windows ou depuis wine. Depuis wine j'ai:
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT"
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT"
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT"
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT"
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT"
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC90.CRT"
err:module:attach_process_dlls "MSVCR90.dll" failed to initialize, aborting
err:module:LdrInitializeThunk Main exe initialization for L"Z:\\mnt\\amber\\world\\QtCreator\\bin\\qtcreator.exe" failed, status c0000142
Il faut y installer le paquetage redistribuable de Visual Studio 2008.
Ou simplement, y joindre tout le dossier de Microsoft.VC90.CRT, fichier .manifest compris.
Déjà fait, mais ça n'as pas l'aire de passer.