Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Probleme avec le fichier executable
bonsoir,
je viens d'ecrire un programme sous Visual C++ 2005. Je voudrais savoir comment je peux le deployer sous d'autres machines.
En fait j'ai copie son executable puis j'ai essaye de l'executer sur d'autres ordis, je me suis rendu compte que sur certaines machines cela marche mais sur d'autres cela ne marche pas (Windows refuse de l'executer sous pretexte que l'application n'est pas bien configuree). Qu'est ce qui peux en etre la cause?
Comment remedier a cette situation?
Merci d'avance
Il faut que tu fournisses les DLL de ton programme avec, et bien souvent aussi celle du Run Time : MSVCRT71.dll etc...
Faut que tu compile tous en release.
En debug, visual fait du pseudo code machine (je sais pas trop en faite) qui ne se lance que lorsque que l'environnement VISUAL 2005 est installé sur la machine. Il faut donc que toute les lib et l'exe soit compilé en release
En fait c'est surtout qu'en mode debug, en général, Visual compile avec les libs "debug" (msvcrtD), qui ne sont PAS redistribuables !
Sinon, effectivement, il manque probablement des DLLs...
Mais pourquoi diable compiler avec la runtime en dll ?
Bonjour,
franc82 écrit :
Et que fait-il ce programme ?bonsoir,
je viens d'ecrire un programme sous Visual C++ 2005. Je voudrais savoir comment je peux le deployer sous d'autres machines.
En fait j'ai copie son executable puis j'ai essaye de l'executer sur d'autres ordis, je me suis rendu compte que sur certaines machines cela marche mais sur d'autres cela ne marche pas (Windows refuse de l'executer sous pretexte que l'application n'est pas bien configuree). Qu'est ce qui peux en etre la cause?
Comment remedier a cette situation?
Merci d'avance
Salut.
Salut,
Il faut que tu installes vcredist_x86.exe sur les machines cible (ou la version SP1 si tu utilises msvc 8 avec le Service Pack 1, il y a un lien en page de la page).
C'est la procédure recommandée pour installer les dll système, l'autre solution étant d'installer visual studio lui-même, ce qui n'est pas très pratique...
MAT.
Oui... de toute maniere, le redist est fourni dans Visual.Envoyé par Mat007
Mais le redistribuable ne contient QUE les versions release !
Et surtout illégal !
Pas dans la version express...
Il est interdit de distribuer une version debug de son application de toute manière...
On peut toujours demander aux utilisateurs d'installer la version express j'imagineEt surtout illégal !
MAT.
Attendez, vous êtes quand même pas en train de raconter qu'il faudrait un pack de distribution pour un programme compilé en Release avec Visual Studio ?
Ca n'a pas grand chose à voir avec Visual....
Si un executable est compilé avec le runtime en "dynamique", l'executable aura besoin de ce runtime installé sur la machine cible (que ce soit du .so, du .dll,...).
Si compilé avec le runtime en static, non, bien sur !
Pour récapituler il faut toujours compiler en release puis utiliser l'une des possibilités suivantes:
- installer le pack redistribuable qui a déja été donné (pas hyper pratique)
- fournir avec l'exe les 2 ou 3 dlls contenus dans le pack (aussi disponibles dans un dossier "Redist" à l'install de visual 2005 pro ou encore sur le net mais faut trouver)
- compiler en mode statique, mais ce n'est pas forcément facile à trouver dans VC et ça m'a déja posé des problèmes (mais j'avoue ne pas m'être acharné dessus)
Considérer aussi la solution ultime qui fonctionne toujours sans se poser de questions: utiliser mingw
Si, car sous visual ces dlls sont nécessaires même pour un hello world, sauf si on compile en runtime static mais la comme je dis c'est pas simple.
Il me semble qu'il faut éviter cela. Car vcredist_x86.exe va installer les bonne dll pour le bon OS. Pas exemple sous vista, se n'est pas les même dll que XP.
Enfin c'est ce que j'avais compris. De plus je croit qu"il est interdit pas la licence de distribuer ces dll comme cela.
Et surtout ce n'est pas aussi simple : il faut aussi fournir avec un fichier manifest pour indiquer que les dll sont avec l'application. Par défaut le manifest inclus avec l'exe indique d'aller chercher les dll système dans le 'native assembly cache'.
Pour plus d'informations : http://msdn2.microsoft.com/en-us/library/ms235532.aspx
(mettre une dll avec l'exe s'appelle 'private assembly')
MAT.
Je ne pense pas, vu qu'elles sont fournies telles qu'elles avec la version pro et approximativement... partout sur le net en vrac. Il y a d'ailleurs beaucoup beaucoup de programmes qui les installent silencieusement (ce qui explique que parfois ça marche sur certains ordis ne possédant pas VC). Mais tu as peut-être raison pour la version de l'os, n'empèche que c'est odieusement énervant de devoir faire une solution de déploiement complexe avec install d'un runtime pour un langage compilé en code natif (sniff, dire que l'absence de machine virtuelle à déployer est l'un des seuls avantages).
Boh, je l'ai déja fait en copiant bètement les dlls dans le dossier de l'exe et ça passait. Faudra m'expliquer alors.
J'avais essayé une fois, et les dll ne marchaient pas. Il manquais des entrées.
C'est peut être les installer fait avec visual.
Oui moi aussi. Et des fois pas.
J'ai l'impression qu'ils ont changé des trucs entre la version (express) RTM et SP1 en plus. Peut-être que par défaut le manifest inclus indique de chercher d'abord dans le répertoire courant maintenant (ou inversement).
MAT.
Je pense que n'importe quel installeur peut installer (silencieusement) ces dll, j'utilise par exemple NSIS et je lance un vcredist_x86.exe sournois et caché à la fin et hop ni vu ni connu !
MAT.
Je ne pense pas, j'ai jamais vu ce truc utilisé nulle part et je crois aussi que ça n'est utile que pour le dotnet.
Je me dit que j'ai vachement bien fait de passer à mingw moi
Hé hé hé...Je pense que n'importe quel installeur peut installer (silencieusement) ces dll, j'utilise par exemple NSIS et je lance un vcredist_x86.exe sournois et caché à la fin et hop ni vu ni connu !
MAT.
Je me demande si je vais pas faire la même chose....
J'utilise installJammer et je crois qu'on peut faire ça.
Au fait, quand j'y pense, je sais pas comment on fait pour compiler en static sous Visual...
Répondre avec citation
Partager