j'ai fait une petite application avec Visual Studio 2005, pour un copain.
Ça a toujours bien fonctionné chez lui, jusqu'à ce qu'il ait réinstallé
son système (XP).
Depuis, il a un message disant que l'appli est pas bien installée, or
cette appli est sensée tourner sans être installée. C'est une simple
Form dans une fenêtre.
Ça tourne chez moi (XP aussi) sans être installée.
Qu'est-ce qui peut provoquer ce genre de problème ?
j'ai fait une petite application avec Visual Studio 2005, pour un copain. Ça a toujours bien fonctionné chez lui, jusqu'à ce qu'il ait réinstallé son système (XP). Depuis, il a un message disant que l'appli est pas bien installée, or cette appli est sensée tourner sans être installée. C'est une simple Form dans une fenêtre. Ça tourne chez moi (XP aussi) sans être installée.
Qu'est-ce qui peut provoquer ce genre de problème ?
Un mauvais déploiement et mauvaises dépendances Voir sur Msdn http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
Achim Bombota wrote:
Bonjour
j'ai fait une petite application avec Visual Studio 2005, pour un copain.
Ça a toujours bien fonctionné chez lui, jusqu'à ce qu'il ait réinstallé
son système (XP).
Depuis, il a un message disant que l'appli est pas bien installée, or
cette appli est sensée tourner sans être installée. C'est une simple
Form dans une fenêtre.
Ça tourne chez moi (XP aussi) sans être installée.
Qu'est-ce qui peut provoquer ce genre de problème ?
Un mauvais déploiement et mauvaises dépendances
Voir sur Msdn
http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
j'ai fait une petite application avec Visual Studio 2005, pour un copain. Ça a toujours bien fonctionné chez lui, jusqu'à ce qu'il ait réinstallé son système (XP). Depuis, il a un message disant que l'appli est pas bien installée, or cette appli est sensée tourner sans être installée. C'est une simple Form dans une fenêtre. Ça tourne chez moi (XP aussi) sans être installée.
Qu'est-ce qui peut provoquer ce genre de problème ?
Un mauvais déploiement et mauvaises dépendances Voir sur Msdn http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
Achim Bombota
Le 29/03/2010 12:33, alain a écrit :
Un mauvais déploiement et mauvaises dépendances Voir sur Msdn http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
OK. Vu que ce serait un peu gros par mail, j'ai envoyé le copain sur le lien où il pourra télécharger les redist de base. J'espère qu'il va s'en sortir.
Merci pour lui !
Le 29/03/2010 12:33, alain a écrit :
Un mauvais déploiement et mauvaises dépendances
Voir sur Msdn
http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
OK.
Vu que ce serait un peu gros par mail, j'ai envoyé le copain sur le lien
où il pourra télécharger les redist de base.
J'espère qu'il va s'en sortir.
Un mauvais déploiement et mauvaises dépendances Voir sur Msdn http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
OK. Vu que ce serait un peu gros par mail, j'ai envoyé le copain sur le lien où il pourra télécharger les redist de base. J'espère qu'il va s'en sortir.
Merci pour lui !
Achim Bombota
Le 29/03/2010 12:33, alain a écrit :
Un mauvais déploiement et mauvaises dépendances Voir sur Msdn http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
et aux dernières nouvelles ça se lance toujours pas.
Y aurait-il un moyen de connaître les dll impliquées lors de l'exécution de l'appli ?
Jean-Claude BELLAMY
"Achim Bombota" a écrit dans le message de groupe de discussion : 4bb1a97a$0$15860$
Le 29/03/2010 12:33, alain a écrit :
Un mauvais déploiement et mauvaises dépendances Voir sur Msdn http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
[...] le copain a fait l'installation de ceci : <http://www.microsoft.com/downloads/details.aspx?FamilyId2BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en>
et aux dernières nouvelles ça se lance toujours pas. Y aurait-il un moyen de connaître les dll impliquées lors de l'exécution de l'appli ?
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées : - "statiquement", c'est-à-dire dès la conception de l'appli, les noms des DLL étant explicitement donnés (par une instruction "external" en Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en VB, ...)
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de l'exécution du programme par un appel de la fonction "loadlibrary", le nom de chaque DLL étant alors une donnée comme une autre, pouvant éventuellement être codée ou cryptée.
Des outils tels que "Dependency Walker" (http://www.dependencywalker.com/) affichent la liste des DLL appelées statiquement.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur hexadécimal, être patient et avoir de la chance !
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Achim Bombota" <bicarbon@e.invalid> a écrit dans le message de groupe de
discussion : 4bb1a97a$0$15860$ba4acef3@reader.news.orange.fr...
Le 29/03/2010 12:33, alain a écrit :
Un mauvais déploiement et mauvaises dépendances
Voir sur Msdn
http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
[...]
le copain a fait l'installation de ceci :
<http://www.microsoft.com/downloads/details.aspx?FamilyId2BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en>
et aux dernières nouvelles ça se lance toujours pas.
Y aurait-il un moyen de connaître les dll impliquées lors de l'exécution
de l'appli ?
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées :
- "statiquement", c'est-à-dire dès la conception de l'appli, les noms des
DLL étant explicitement donnés (par une instruction "external" en
Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en VB,
...)
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de l'exécution
du programme par un appel de la fonction "loadlibrary", le nom de chaque DLL
étant alors une donnée comme une autre, pouvant éventuellement être codée ou
cryptée.
Des outils tels que "Dependency Walker" (http://www.dependencywalker.com/)
affichent la liste des DLL appelées statiquement.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur
hexadécimal, être patient et avoir de la chance !
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
"Achim Bombota" a écrit dans le message de groupe de discussion : 4bb1a97a$0$15860$
Le 29/03/2010 12:33, alain a écrit :
Un mauvais déploiement et mauvaises dépendances Voir sur Msdn http://msdn.microsoft.com/en-us/library/8kche8ah.aspx
[...] le copain a fait l'installation de ceci : <http://www.microsoft.com/downloads/details.aspx?FamilyId2BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en>
et aux dernières nouvelles ça se lance toujours pas. Y aurait-il un moyen de connaître les dll impliquées lors de l'exécution de l'appli ?
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées : - "statiquement", c'est-à-dire dès la conception de l'appli, les noms des DLL étant explicitement donnés (par une instruction "external" en Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en VB, ...)
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de l'exécution du programme par un appel de la fonction "loadlibrary", le nom de chaque DLL étant alors une donnée comme une autre, pouvant éventuellement être codée ou cryptée.
Des outils tels que "Dependency Walker" (http://www.dependencywalker.com/) affichent la liste des DLL appelées statiquement.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur hexadécimal, être patient et avoir de la chance !
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
rm
Salut, Le mardi 30 mars 2010 à 10:33, Jean-Claude BELLAMY a écrit :
Des outils tels que "Dependency Walker" (http://www.dependencywalker.com/) affichent la liste des DLL appelées statiquement.
Pas uniquement ! Souviens toi : http://www.generation-nt.com/reponses/liste-des-dll-d-une-application-entraide-1845131.html#9794471
;-)
@+ -- rm
Salut,
Le mardi 30 mars 2010 à 10:33, Jean-Claude BELLAMY a écrit :
Des outils tels que "Dependency Walker" (http://www.dependencywalker.com/)
affichent la liste des DLL appelées statiquement.
Pas uniquement !
Souviens toi :
http://www.generation-nt.com/reponses/liste-des-dll-d-une-application-entraide-1845131.html#9794471
Salut, Le mardi 30 mars 2010 à 10:33, Jean-Claude BELLAMY a écrit :
Des outils tels que "Dependency Walker" (http://www.dependencywalker.com/) affichent la liste des DLL appelées statiquement.
Pas uniquement ! Souviens toi : http://www.generation-nt.com/reponses/liste-des-dll-d-une-application-entraide-1845131.html#9794471
;-)
@+ -- rm
Achim Bombota
Le 30/03/2010 10:33, Jean-Claude BELLAMY a écrit :
Bonjour
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées : - "statiquement", c'est-à-dire dès la conception de l'appli, les noms des DLL étant explicitement donnés (par une instruction "external" en Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en VB, ...)
C'est pas le cas, je suis parti d'un exemple de Form de base en C++ et je me souviens pas avoir explicitement donné des noms de DLL, le projet date de 2007 et j'aurais bien eu du mal à savoir de quelles DLL j'avais besoin...
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de l'exécution du programme par un appel de la fonction "loadlibrary", le nom de chaque DLL étant alors une donnée comme une autre, pouvant éventuellement être codée ou cryptée.
Pas de loadlibrary non plus.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur hexadécimal, être patient et avoir de la chance !
J'ai donc lancé en mode debug et en sortie j'ai eu : pour mon exe, symboles chargés. puis msvcm80d.dll chargé, symboles chargés. et aussi System.dll' chargé, chargement des symboles ignoré. Le module est optimisé et l'option du débogueur 'Uniquement mon code' est activée.
Le chemin qui mène à msvcm80d.dll contient x86 et Debug, je suppose donc qu'il lui faut msvcm80.dll pour la version release et en version amd64 si son portable est amd :)
Merci de m'avoir rappelé que le débogueur avait une sortie !
Le 30/03/2010 10:33, Jean-Claude BELLAMY a écrit :
Bonjour
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées :
- "statiquement", c'est-à-dire dès la conception de l'appli, les noms
des DLL étant explicitement donnés (par une instruction "external" en
Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en
VB, ...)
C'est pas le cas, je suis parti d'un exemple de Form de base en C++ et
je me souviens pas avoir explicitement donné des noms de DLL, le projet
date de 2007 et j'aurais bien eu du mal à savoir de quelles DLL j'avais
besoin...
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de
l'exécution du programme par un appel de la fonction "loadlibrary", le
nom de chaque DLL étant alors une donnée comme une autre, pouvant
éventuellement être codée ou cryptée.
Pas de loadlibrary non plus.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur
hexadécimal, être patient et avoir de la chance !
J'ai donc lancé en mode debug et en sortie j'ai eu :
pour mon exe, symboles chargés.
puis msvcm80d.dll chargé, symboles chargés.
et aussi System.dll' chargé, chargement des symboles ignoré. Le module
est optimisé et l'option du débogueur 'Uniquement mon code' est activée.
Le chemin qui mène à msvcm80d.dll contient x86 et Debug, je suppose donc
qu'il lui faut msvcm80.dll pour la version release et en version amd64
si son portable est amd :)
Merci de m'avoir rappelé que le débogueur avait une sortie !
Le 30/03/2010 10:33, Jean-Claude BELLAMY a écrit :
Bonjour
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées : - "statiquement", c'est-à-dire dès la conception de l'appli, les noms des DLL étant explicitement donnés (par une instruction "external" en Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en VB, ...)
C'est pas le cas, je suis parti d'un exemple de Form de base en C++ et je me souviens pas avoir explicitement donné des noms de DLL, le projet date de 2007 et j'aurais bien eu du mal à savoir de quelles DLL j'avais besoin...
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de l'exécution du programme par un appel de la fonction "loadlibrary", le nom de chaque DLL étant alors une donnée comme une autre, pouvant éventuellement être codée ou cryptée.
Pas de loadlibrary non plus.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur hexadécimal, être patient et avoir de la chance !
J'ai donc lancé en mode debug et en sortie j'ai eu : pour mon exe, symboles chargés. puis msvcm80d.dll chargé, symboles chargés. et aussi System.dll' chargé, chargement des symboles ignoré. Le module est optimisé et l'option du débogueur 'Uniquement mon code' est activée.
Le chemin qui mène à msvcm80d.dll contient x86 et Debug, je suppose donc qu'il lui faut msvcm80.dll pour la version release et en version amd64 si son portable est amd :)
Merci de m'avoir rappelé que le débogueur avait une sortie !
Achim Bombota
Bonjour
exe à problème le retour. Rappel : il s'agit d'une appli que j'ai développée au seul usage d'un ami et cette appli a cessé de fonctionner après qu'il ait réinstallé son système. Suite aux dernières discussions ici, je lui ai donc envoyé l'exe en compagnie de la msvcm80.dll. Comme il lit ses mails sur yahoo, qu'il ne sait pas forcément rapatrier les pièces jointes et qu'il fait un blocage quand je lui parle de .zip, il a donc fait appel à une amie plus proche de chez lui pour tout récupérer. Ça fait plus d'un mois déjà et j'ai enfin une réponse comme quoi "L'application n'a pas pu démarrer car sa configuration côte-à-côte est incorrecte". La dll étant placée dans le même répertoire que l'exe. J'ignore le système utilisé par l'amie de l'ami, mais ça ressemble à Vista.
Est-il possible avec Visual Studio 2005 de faire un exe qui soit réellement autonome, capable d'inclure toutes les librairies nécessaires sans installation ?
ci-dessous le dernier échange ici, pour mémoire, je sais que ça se fait pas mais veuillez considérer ce message comme un nouveau message.
Le 30/03/2010 10:33, Jean-Claude BELLAMY a écrit :
Bonjour
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées : - "statiquement", c'est-à-dire dès la conception de l'appli, les noms des DLL étant explicitement donnés (par une instruction "external" en Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en VB, ...)
C'est pas le cas, je suis parti d'un exemple de Form de base en C++ et je me souviens pas avoir explicitement donné des noms de DLL, le projet date de 2007 et j'aurais bien eu du mal à savoir de quelles DLL j'avais besoin...
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de l'exécution du programme par un appel de la fonction "loadlibrary", le nom de chaque DLL étant alors une donnée comme une autre, pouvant éventuellement être codée ou cryptée.
Pas de loadlibrary non plus.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur hexadécimal, être patient et avoir de la chance !
J'ai donc lancé en mode debug et en sortie j'ai eu : pour mon exe, symboles chargés. puis msvcm80d.dll chargé, symboles chargés. et aussi System.dll' chargé, chargement des symboles ignoré. Le module est optimisé et l'option du débogueur 'Uniquement mon code' est activée.
Le chemin qui mène à msvcm80d.dll contient x86 et Debug, je suppose donc qu'il lui faut msvcm80.dll pour la version release et en version amd64 si son portable est amd :)
Merci de m'avoir rappelé que le débogueur avait une sortie !
Bonjour
exe à problème le retour.
Rappel : il s'agit d'une appli que j'ai développée au seul usage d'un
ami et cette appli a cessé de fonctionner après qu'il ait réinstallé son
système.
Suite aux dernières discussions ici, je lui ai donc envoyé l'exe en
compagnie de la msvcm80.dll. Comme il lit ses mails sur yahoo, qu'il ne
sait pas forcément rapatrier les pièces jointes et qu'il fait un blocage
quand je lui parle de .zip, il a donc fait appel à une amie plus proche
de chez lui pour tout récupérer.
Ça fait plus d'un mois déjà et j'ai enfin une réponse comme quoi
"L'application n'a pas pu démarrer car sa configuration côte-à-côte est
incorrecte".
La dll étant placée dans le même répertoire que l'exe.
J'ignore le système utilisé par l'amie de l'ami, mais ça ressemble à Vista.
Est-il possible avec Visual Studio 2005 de faire un exe qui soit
réellement autonome, capable d'inclure toutes les librairies nécessaires
sans installation ?
ci-dessous le dernier échange ici, pour mémoire, je sais que ça se fait
pas mais veuillez considérer ce message comme un nouveau message.
Le 30/03/2010 10:33, Jean-Claude BELLAMY a écrit :
Bonjour
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées :
- "statiquement", c'est-à-dire dès la conception de l'appli, les noms
des DLL étant explicitement donnés (par une instruction "external" en
Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en
VB, ...)
C'est pas le cas, je suis parti d'un exemple de Form de base en C++ et
je me souviens pas avoir explicitement donné des noms de DLL, le projet
date de 2007 et j'aurais bien eu du mal à savoir de quelles DLL j'avais
besoin...
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de
l'exécution du programme par un appel de la fonction "loadlibrary", le
nom de chaque DLL étant alors une donnée comme une autre, pouvant
éventuellement être codée ou cryptée.
Pas de loadlibrary non plus.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur
hexadécimal, être patient et avoir de la chance !
J'ai donc lancé en mode debug et en sortie j'ai eu :
pour mon exe, symboles chargés.
puis msvcm80d.dll chargé, symboles chargés.
et aussi System.dll' chargé, chargement des symboles ignoré. Le module
est optimisé et l'option du débogueur 'Uniquement mon code' est activée.
Le chemin qui mène à msvcm80d.dll contient x86 et Debug, je suppose donc
qu'il lui faut msvcm80.dll pour la version release et en version amd64
si son portable est amd :)
Merci de m'avoir rappelé que le débogueur avait une sortie !
exe à problème le retour. Rappel : il s'agit d'une appli que j'ai développée au seul usage d'un ami et cette appli a cessé de fonctionner après qu'il ait réinstallé son système. Suite aux dernières discussions ici, je lui ai donc envoyé l'exe en compagnie de la msvcm80.dll. Comme il lit ses mails sur yahoo, qu'il ne sait pas forcément rapatrier les pièces jointes et qu'il fait un blocage quand je lui parle de .zip, il a donc fait appel à une amie plus proche de chez lui pour tout récupérer. Ça fait plus d'un mois déjà et j'ai enfin une réponse comme quoi "L'application n'a pas pu démarrer car sa configuration côte-à-côte est incorrecte". La dll étant placée dans le même répertoire que l'exe. J'ignore le système utilisé par l'amie de l'ami, mais ça ressemble à Vista.
Est-il possible avec Visual Studio 2005 de faire un exe qui soit réellement autonome, capable d'inclure toutes les librairies nécessaires sans installation ?
ci-dessous le dernier échange ici, pour mémoire, je sais que ça se fait pas mais veuillez considérer ce message comme un nouveau message.
Le 30/03/2010 10:33, Jean-Claude BELLAMY a écrit :
Bonjour
Avec une fiabilité du résultat de 100%, non, ce n'est pas possible.
Tout dépend si les DLL sont appelées : - "statiquement", c'est-à-dire dès la conception de l'appli, les noms des DLL étant explicitement donnés (par une instruction "external" en Delphi/Pascal, dans un fichier .def en C/C++, une instruction "lib" en VB, ...)
C'est pas le cas, je suis parti d'un exemple de Form de base en C++ et je me souviens pas avoir explicitement donné des noms de DLL, le projet date de 2007 et j'aurais bien eu du mal à savoir de quelles DLL j'avais besoin...
- "dynamiquement", c'est-à-dire au "fil de l'eau", au cours de l'exécution du programme par un appel de la fonction "loadlibrary", le nom de chaque DLL étant alors une donnée comme une autre, pouvant éventuellement être codée ou cryptée.
Pas de loadlibrary non plus.
Pour les autres il faut utiliser un débogueur, à défaut un éditeur hexadécimal, être patient et avoir de la chance !
J'ai donc lancé en mode debug et en sortie j'ai eu : pour mon exe, symboles chargés. puis msvcm80d.dll chargé, symboles chargés. et aussi System.dll' chargé, chargement des symboles ignoré. Le module est optimisé et l'option du débogueur 'Uniquement mon code' est activée.
Le chemin qui mène à msvcm80d.dll contient x86 et Debug, je suppose donc qu'il lui faut msvcm80.dll pour la version release et en version amd64 si son portable est amd :)
Merci de m'avoir rappelé que le débogueur avait une sortie !
Vincent Burel
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème. Il vous dira s'il manque un module à votre exe, et lequel.
VB
"Achim Bombota" wrote in message news:4beaa8f7$0$2965$
Bonjour
exe à problème le retour. Rappel : il s'agit d'une appli que j'ai développée au seul usage d'un ami et cette appli a cessé de fonctionner après qu'il ait réinstallé son système. Suite aux dernières discussions ici, je lui ai donc envoyé l'exe en compagnie de la msvcm80.dll. Comme il lit ses mails sur yahoo, qu'il ne sait pas forcément rapatrier les pièces jointes et qu'il fait un blocage quand je lui parle de .zip, il a donc fait appel à une amie plus proche de chez lui pour tout récupérer. Ça fait plus d'un mois déjà et j'ai enfin une réponse comme quoi "L'application n'a pas pu démarrer car sa configuration côte-à-côte est incorrecte". La dll étant placée dans le même répertoire que l'exe. J'ignore le système utilisé par l'amie de l'ami, mais ça ressemble à
Vista.
Est-il possible avec Visual Studio 2005 de faire un exe qui soit réellement autonome, capable d'inclure toutes les librairies nécessaires sans installation ?
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème.
Il vous dira s'il manque un module à votre exe, et lequel.
VB
"Achim Bombota" <bicarbon@e.invalid> wrote in message
news:4beaa8f7$0$2965$ba4acef3@reader.news.orange.fr...
Bonjour
exe à problème le retour.
Rappel : il s'agit d'une appli que j'ai développée au seul usage d'un
ami et cette appli a cessé de fonctionner après qu'il ait réinstallé son
système.
Suite aux dernières discussions ici, je lui ai donc envoyé l'exe en
compagnie de la msvcm80.dll. Comme il lit ses mails sur yahoo, qu'il ne
sait pas forcément rapatrier les pièces jointes et qu'il fait un blocage
quand je lui parle de .zip, il a donc fait appel à une amie plus proche
de chez lui pour tout récupérer.
Ça fait plus d'un mois déjà et j'ai enfin une réponse comme quoi
"L'application n'a pas pu démarrer car sa configuration côte-à-côte est
incorrecte".
La dll étant placée dans le même répertoire que l'exe.
J'ignore le système utilisé par l'amie de l'ami, mais ça ressemble à
Vista.
Est-il possible avec Visual Studio 2005 de faire un exe qui soit
réellement autonome, capable d'inclure toutes les librairies nécessaires
sans installation ?
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème. Il vous dira s'il manque un module à votre exe, et lequel.
VB
"Achim Bombota" wrote in message news:4beaa8f7$0$2965$
Bonjour
exe à problème le retour. Rappel : il s'agit d'une appli que j'ai développée au seul usage d'un ami et cette appli a cessé de fonctionner après qu'il ait réinstallé son système. Suite aux dernières discussions ici, je lui ai donc envoyé l'exe en compagnie de la msvcm80.dll. Comme il lit ses mails sur yahoo, qu'il ne sait pas forcément rapatrier les pièces jointes et qu'il fait un blocage quand je lui parle de .zip, il a donc fait appel à une amie plus proche de chez lui pour tout récupérer. Ça fait plus d'un mois déjà et j'ai enfin une réponse comme quoi "L'application n'a pas pu démarrer car sa configuration côte-à-côte est incorrecte". La dll étant placée dans le même répertoire que l'exe. J'ignore le système utilisé par l'amie de l'ami, mais ça ressemble à
Vista.
Est-il possible avec Visual Studio 2005 de faire un exe qui soit réellement autonome, capable d'inclure toutes les librairies nécessaires sans installation ?
Achim Bombota
Le 13/05/2010 11:54, Vincent Burel a écrit :
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème. Il vous dira s'il manque un module à votre exe, et lequel.
VB
Merci Vincent.
Reste plus qu'à expliquer au copain comment faire fonctionner ça sur son pc.
Le 13/05/2010 11:54, Vincent Burel a écrit :
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème.
Il vous dira s'il manque un module à votre exe, et lequel.
VB
Merci Vincent.
Reste plus qu'à expliquer au copain comment faire fonctionner ça sur son pc.
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème. Il vous dira s'il manque un module à votre exe, et lequel.
VB
Merci Vincent.
Reste plus qu'à expliquer au copain comment faire fonctionner ça sur son pc.
Achim Bombota
Le 13/05/2010 11:54, Vincent Burel a écrit :
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème. Il vous dira s'il manque un module à votre exe, et lequel.
VB
Re,
j'ai essayé sur un Vista chez moi et j'ai la même erreur. D'après le journal d'évènements il s'agit de microsoft.vc80.crt qui n'est pas là. J'ai bien essayé de lui copier ma msvcr80.dll mais on a un conflit de version. Si j'ai bien compris, faut que je potasse les histoires de manifest, pour que ça puisse tourner quel que soit le numéro de version.
Le 13/05/2010 11:54, Vincent Burel a écrit :
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème.
Il vous dira s'il manque un module à votre exe, et lequel.
VB
Re,
j'ai essayé sur un Vista chez moi et j'ai la même erreur.
D'après le journal d'évènements il s'agit de microsoft.vc80.crt qui
n'est pas là.
J'ai bien essayé de lui copier ma msvcr80.dll mais on a un conflit de
version.
Si j'ai bien compris, faut que je potasse les histoires de manifest,
pour que ça puisse tourner quel que soit le numéro de version.
Vous pouvez utiliser "Dependency Walker"' sur la config qui pose problème. Il vous dira s'il manque un module à votre exe, et lequel.
VB
Re,
j'ai essayé sur un Vista chez moi et j'ai la même erreur. D'après le journal d'évènements il s'agit de microsoft.vc80.crt qui n'est pas là. J'ai bien essayé de lui copier ma msvcr80.dll mais on a un conflit de version. Si j'ai bien compris, faut que je potasse les histoires de manifest, pour que ça puisse tourner quel que soit le numéro de version.
