Bonjour bonjour,
J'ai developpé un lourd programme en Visual C++ (version 2005 du studio), et je me demandais, si pour utiliser cette aplicatif, il pouvait suffir de copier mon dossier sur un autre PC et de double cliquer sur le .exe?
Version imprimable
Bonjour bonjour,
J'ai developpé un lourd programme en Visual C++ (version 2005 du studio), et je me demandais, si pour utiliser cette aplicatif, il pouvait suffir de copier mon dossier sur un autre PC et de double cliquer sur le .exe?
Bonjour,
La réponse dépend des bibliothèques avec lesquelles le soft a été lié.
WIN32 / MFC static : besoin de rien.
MFC DLL : besoin de la dll MFCxx.dll.
.net : besoin d'installer sur le poste client le redistribuable .net correspondant au moins à la version de développement.
aaarf
C'est une appli WIN32 et cela testicule (politesse oblige)
Quand vous dites de cela ne fonctionne pas, quel est le message d'erreur envoyé ?
Dans properties / projects defaults, quelle est l'entrée pour "use MFC" ?
Que quelles DLL dépend cette application ? (Voir ça avec dependencywalker qui est installé avec certaines versions de VS, à télécharger sinon)
use MFC : Utiliser les bibliothèques Windows standard
Erreur retournée : Cette application n'a pas pu démarrer car la configuration de l'application est incorrecte. Réinstaller l'application pourrait résoudre le problème.
Dépendance :
msvcp80d.dll
msvcr80d.dll
kernel32.dll
msvcp80d.dll : MicroSoft Visual C Plusplus (?) 8.0Citation:
msvcp80d.dll
msvcr80d.dll
msvcr80d.dll : MicroSoft Visual C Runtime 8.0
Ces deux bibliothèques sont à fournir avec l'exécutable pour que le soft se lance correctement.
Deux solutions :
- Mettre les dll dans le répertoire d'exécution de l'appli
- Copier les dll dans le path du poste cible (genre c:\windows\system32)
- Solution bonus : passer par un installateur comme celui de nullsoft par exemple.
kernel32.dll est installé sur tous les windows
J'ajouterais juste que les deux sont des version debug.Citation:
Envoyé par mabu
Tu veux distribuer une version debug 8O :koi: ?Je crois (à 90% :D) par expérience que ça ne suffit pas pour VS2005. Pour distribuer du release, il te faut passer par le pack de redistribution, disponible dans la FAQ.Citation:
Envoyé par mabu
A noter également ce lien, qui te concerne peut-être plus pour le debug.
Troisième solution, mille fois plus simple, les lier en statique (Project / Properties / C/C++ / Code Generation / Runtime Library = Multi-threaded)
Alors sous ma première question simple se cache un réelle probleme que vous allez retrouver sur ce post ci
Si vous avez quelques idées que ce soit, maintenant que vous avez toutes les données du problème, je suis preneur.
(vous verrez sur le lien, que j'ai deja installé vcredist_x86.exe sur mon autre PC et ca n'a pas aidé. Il doit y avoir une subtilité du vs2005 que je ne connais pas encore)
Normal, tu veux distribuer une version debug!Citation:
Envoyé par Hanz Peter Mariol
Normalement, on ne distribue que du release (msvcp80.dll et msvcr80.dll, pas de 'd' à la fin). Et ce sont ces deux DLL que vc_redist installe, pas les versions debug.
De plus, je crois que les version debug des DLL msvcp80.dll n'ont pas le droit d'être déployées comme cela car elles nécessitent une licence Visual sur le poste sur lequel on les copie
Et comment passer en version release?
Vu que tu utilises Visual:
Menu Générer >> Gestionnaire de configurations >> Release
Bon ba j'ai mis en release,
Bibliothèque runtimes -> DLL multithread
Mais cela me lance toujours la meme erreur, c'est à n'y rien comprendre : "Cette application n'a pas pu démarrer car la configuration de l'application est incorrecte. Réinstaller l'application pour résoudre ce problème"
Quel est exactement la procédure ou les paramètre à mettre pour déployer une application vc++2005? Juste ce qu'il y a en début de message?
(en tout cas je vous remercie pour le temps que vous m'accordez)
Ah oui et apres avoir mis en release mes dépendance sont :
msvcp80d
msvcr80
Pas normal que la version Debug soit encore référencée...
Parfaitement d'accord. Ca n'a changé que la seconde. La première serait elle dépendante d'un autre paramètre de la configuration?
Ou alors les options de la configuration "release" ne correspondent pas à une version release et ont été bidouillées :roll:
Je ne pense pas, j'ai été le seul à utiliser Visual sur ce PC et étant donné que je n'y connais absolument rien, je me suis contenter de coder ma solution au problème et de la tester avec des "Executer".
Après si tu as une idée de l'option qui peut en être responsable je peux y farfouiller
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.