Version imprimable
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 :aie:) 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 ?Citation:
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.Citation:
Envoyé par Mat007
Mais le redistribuable ne contient QUE les versions release !
Et surtout illégal ! :DCitation:
Envoyé par Mat007
Pas dans la version express...Citation:
Envoyé par nicroman
Il est interdit de distribuer une version debug de son application de toute manière...Citation:
Envoyé par nicroman
On peut toujours demander aux utilisateurs d'installer la version express j'imagine :)Citation:
Envoyé par nicroman
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 ? 8O
:aie:
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 ! :D
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 :D
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.Citation:
Envoyé par nicroman
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.Citation:
Envoyé par zais_ethael
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'.Citation:
Envoyé par zais_ethael
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.Citation:
Envoyé par Mat007
J'avais essayé une fois, et les dll ne marchaient pas. Il manquais des entrées.Citation:
Envoyé par zais_ethael
C'est peut être les installer fait avec visual.Citation:
Envoyé par zais_ethael
:lol:Citation:
Envoyé par zais_ethael
Oui moi aussi. Et des fois pas. :aie:Citation:
Envoyé par zais_ethael
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 ! :roll:Citation:
Envoyé par Mongaulois
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.Citation:
Envoyé par Mongaulois
Je me dit que j'ai vachement bien fait de passer à mingw moi :D Vive les programmes qui font correctement leur boulot!
Hé hé hé...Citation:
Envoyé par Mat007
Je me demande si je vais pas faire la même chose.... :chin:
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... :koi:
Bonjour,
Je n'ai pas réponse à tout, mais je peux néanmoins clarifier certaines choses:
- Il n'est pas illégal de distribuer les DLLs en version Release livrées avec Visual. La license interdit seulement la distribution des DLLs de débogage.
- Les outils de déploiement de VS2005 peuvent lister les DLLs appropriées dans les "dépendances à installer avec l'application".
En fait... rien de plus simple:Citation:
Envoyé par poukill
Propriétés du projet...
Selection de la/les configuration(s) et de la/les plateform(es)...
Configuration properties
C/C++
Code Generation
-> Runtime Libraries
Y a les 4 choix possibles: release, debug, release-DLL, debug-DLL
Juste une information additionelle... Sous visual, la création d'un projet d'installation (donc d'un .msi) permet de gérer tout ça de manière transparente. En plus le projet indique clairement les dépendences sur d'éventuel merge-module manquantes.
Et comme tous les fichiers d'installation M$, les installations peuvent être silencieuses sans aucun problême.
Rappelons que le but est qu'un "programme" puisse toujours être installé par un installeur automatique (pour les silent deployment chers aux administrateurs) et surtout, puisse toujours être désinstallé par le panneau de contrôle ! Il est dépassé le temps ou installer un programme ce faisait à coup de gzip et de set path... heureusement !