Je chercher =E0 r=E9aliser un ex=E9cutable autonome, mais voila
lorsque je cr=E9e un nouveau projet (exe standard) l'option
"Mode d'execution autonome" dans propri=E9t=E9 du projet reste=20
gris=E9 ????
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ng
Salut,
Cette case n'a rien a voir avec une dépendance à un runtime ou non. Elle est utilisée pour les EXE ActiveX.
La seule possibilité de faire des exe autonomes est d'inclure dans l'exe toutes les DLLs du runtime et les OCX utilisés... Il existe des utilitaires pour faire cela :
http://faq.vb.free.fr/index.php?question
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
Fred87 a écrit :
Bonjour à Tous,
Je chercher à réaliser un exécutable autonome, mais voila lorsque je crée un nouveau projet (exe standard) l'option "Mode d'execution autonome" dans propriété du projet reste grisé ????
D'ou peut venir ce problème.
Merci de votre aide
FRED87
Salut,
Cette case n'a rien a voir avec une dépendance à un runtime ou non. Elle est
utilisée pour les EXE ActiveX.
La seule possibilité de faire des exe autonomes est d'inclure dans l'exe
toutes les DLLs du runtime et les OCX utilisés... Il existe des utilitaires
pour faire cela :
http://faq.vb.free.fr/index.php?question
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
http://apisvb.europe.webmatrixhosting.net/
Fred87 <anonymous@discussions.microsoft.com> a écrit :
Bonjour à Tous,
Je chercher à réaliser un exécutable autonome, mais voila
lorsque je crée un nouveau projet (exe standard) l'option
"Mode d'execution autonome" dans propriété du projet reste
grisé ????
Cette case n'a rien a voir avec une dépendance à un runtime ou non. Elle est utilisée pour les EXE ActiveX.
La seule possibilité de faire des exe autonomes est d'inclure dans l'exe toutes les DLLs du runtime et les OCX utilisés... Il existe des utilitaires pour faire cela :
http://faq.vb.free.fr/index.php?question
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
Fred87 a écrit :
Bonjour à Tous,
Je chercher à réaliser un exécutable autonome, mais voila lorsque je crée un nouveau projet (exe standard) l'option "Mode d'execution autonome" dans propriété du projet reste grisé ????
D'ou peut venir ce problème.
Merci de votre aide
FRED87
Vincent Guichard
Fred87 a écrit :
Bonjour à Tous,
Bonjour
Je chercher à réaliser un exécutable autonome, mais voila lorsque je crée un nouveau projet (exe standard) l'option "Mode d'execution autonome" dans propriété du projet reste grisé ????
D'ou peut venir ce problème.
Mode d'execution autonome ne concerne que les composants ActiveX. Un exe standard est toujours autonome (dans la mesure ou un programme VB peut être dit "Autonome"...)
Merci de votre aide
De rien, mais une simple recherche sur le mot autonome dans la MSDN t'aurais donné la réponse.
Vincent Guichard
Fred87 a écrit :
Bonjour à Tous,
Bonjour
Je chercher à réaliser un exécutable autonome, mais voila
lorsque je crée un nouveau projet (exe standard) l'option
"Mode d'execution autonome" dans propriété du projet reste
grisé ????
D'ou peut venir ce problème.
Mode d'execution autonome ne concerne que les composants ActiveX.
Un exe standard est toujours autonome (dans la mesure ou un programme VB
peut être dit "Autonome"...)
Merci de votre aide
De rien, mais une simple recherche sur le mot autonome dans la MSDN
t'aurais donné la réponse.
Je chercher à réaliser un exécutable autonome, mais voila lorsque je crée un nouveau projet (exe standard) l'option "Mode d'execution autonome" dans propriété du projet reste grisé ????
D'ou peut venir ce problème.
Mode d'execution autonome ne concerne que les composants ActiveX. Un exe standard est toujours autonome (dans la mesure ou un programme VB peut être dit "Autonome"...)
Merci de votre aide
De rien, mais une simple recherche sur le mot autonome dans la MSDN t'aurais donné la réponse.
Vincent Guichard
Patrick Philippot
ng wrote:
La seule possibilité de faire des exe autonomes est d'inclure dans l'exe toutes les DLLs du runtime et les OCX utilisés... Il existe des utilitaires pour faire cela :
http://faq.vb.free.fr/index.php?question
Bonjour ng,
Merci pour ce lien, je ne connaissais pas ces produits.
Concernant le texte de la FAQ, il convient peut-être de modérer un peu le propos:
" ...Si vous exécutez votre programme sur un poste qui ne possède pas Visual Basic, celui-ci ne fonctionnera pas. En effet, les programmes réalisés avec VB sont dépendants de toute une série de dll, elles-même parfois dépendantes d'autres dll. Pour distribuer votre application, utilisez l'Assistant Empaquetage & Déploiement (livré avec Visual Basic) qui se chargera de rassembler toutes les dlls requises dans un programme d'installation. "
Rappelons que la seule DLL qui est toujours nécessaire, quelle que soit la nature du code VB distribué et les options de compilation, c'est MSVBVM60.DLL (ou MSVBVMxx.DLL pour les versions de VB pré VB6) et que cette DLL est maintenant systématiquement distribuée avec le système d'exploitation et avec de nombreux produits MS. Ce qui ne veut pas dire qu'il ne faut pas vérifier sa présence à l'installation de l'appli ou du composant.
Le texte de la FAQ devrait préciser que tout code VB6 est *nécessairement* dépendant de MSVBVM60.DLL et éventuellement d'autres DLLs en fonction des technologies et composants utilisés.
Mais dire que si on n'a pas VB6, l'application ne pourra pas fonctionner, c'est un peu excessif (AMHA).
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.fr
ng wrote:
La seule possibilité de faire des exe autonomes est d'inclure dans
l'exe toutes les DLLs du runtime et les OCX utilisés... Il existe des
utilitaires pour faire cela :
http://faq.vb.free.fr/index.php?question
Bonjour ng,
Merci pour ce lien, je ne connaissais pas ces produits.
Concernant le texte de la FAQ, il convient peut-être de modérer un peu
le propos:
"
...Si vous exécutez votre programme sur un poste qui ne possède pas
Visual Basic, celui-ci ne fonctionnera pas. En effet, les programmes
réalisés avec VB sont dépendants de toute une série de dll, elles-même
parfois dépendantes d'autres dll. Pour distribuer votre application,
utilisez l'Assistant Empaquetage & Déploiement (livré avec Visual Basic)
qui se chargera de rassembler toutes les dlls requises dans un programme
d'installation.
"
Rappelons que la seule DLL qui est toujours nécessaire, quelle que soit
la nature du code VB distribué et les options de compilation, c'est
MSVBVM60.DLL (ou MSVBVMxx.DLL pour les versions de VB pré VB6) et que
cette DLL est maintenant systématiquement distribuée avec le système
d'exploitation et avec de nombreux produits MS. Ce qui ne veut pas dire
qu'il ne faut pas vérifier sa présence à l'installation de l'appli ou du
composant.
Le texte de la FAQ devrait préciser que tout code VB6 est
*nécessairement* dépendant de MSVBVM60.DLL et éventuellement d'autres
DLLs en fonction des technologies et composants utilisés.
Mais dire que si on n'a pas VB6, l'application ne pourra pas
fonctionner, c'est un peu excessif (AMHA).
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
La seule possibilité de faire des exe autonomes est d'inclure dans l'exe toutes les DLLs du runtime et les OCX utilisés... Il existe des utilitaires pour faire cela :
http://faq.vb.free.fr/index.php?question
Bonjour ng,
Merci pour ce lien, je ne connaissais pas ces produits.
Concernant le texte de la FAQ, il convient peut-être de modérer un peu le propos:
" ...Si vous exécutez votre programme sur un poste qui ne possède pas Visual Basic, celui-ci ne fonctionnera pas. En effet, les programmes réalisés avec VB sont dépendants de toute une série de dll, elles-même parfois dépendantes d'autres dll. Pour distribuer votre application, utilisez l'Assistant Empaquetage & Déploiement (livré avec Visual Basic) qui se chargera de rassembler toutes les dlls requises dans un programme d'installation. "
Rappelons que la seule DLL qui est toujours nécessaire, quelle que soit la nature du code VB distribué et les options de compilation, c'est MSVBVM60.DLL (ou MSVBVMxx.DLL pour les versions de VB pré VB6) et que cette DLL est maintenant systématiquement distribuée avec le système d'exploitation et avec de nombreux produits MS. Ce qui ne veut pas dire qu'il ne faut pas vérifier sa présence à l'installation de l'appli ou du composant.
Le texte de la FAQ devrait préciser que tout code VB6 est *nécessairement* dépendant de MSVBVM60.DLL et éventuellement d'autres DLLs en fonction des technologies et composants utilisés.
Mais dire que si on n'a pas VB6, l'application ne pourra pas fonctionner, c'est un peu excessif (AMHA).
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.fr
ng
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance aux DLLs satellites, elle peut être supprimée très facilement grace à l'utilitaire vblocal.exe de l'IPDK.
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
Patrick Philippot a écrit :
ng wrote:
La seule possibilité de faire des exe autonomes est d'inclure dans l'exe toutes les DLLs du runtime et les OCX utilisés... Il existe des utilitaires pour faire cela :
http://faq.vb.free.fr/index.php?question
Bonjour ng,
Merci pour ce lien, je ne connaissais pas ces produits.
Concernant le texte de la FAQ, il convient peut-être de modérer un peu le propos:
" ...Si vous exécutez votre programme sur un poste qui ne possède pas Visual Basic, celui-ci ne fonctionnera pas. En effet, les programmes réalisés avec VB sont dépendants de toute une série de dll, elles-même parfois dépendantes d'autres dll. Pour distribuer votre application, utilisez l'Assistant Empaquetage & Déploiement (livré avec Visual Basic) qui se chargera de rassembler toutes les dlls requises dans un programme d'installation. "
Rappelons que la seule DLL qui est toujours nécessaire, quelle que soit la nature du code VB distribué et les options de compilation, c'est MSVBVM60.DLL (ou MSVBVMxx.DLL pour les versions de VB pré VB6) et que cette DLL est maintenant systématiquement distribuée avec le système d'exploitation et avec de nombreux produits MS. Ce qui ne veut pas dire qu'il ne faut pas vérifier sa présence à l'installation de l'appli ou du composant.
Le texte de la FAQ devrait préciser que tout code VB6 est *nécessairement* dépendant de MSVBVM60.DLL et éventuellement d'autres DLLs en fonction des technologies et composants utilisés.
Mais dire que si on n'a pas VB6, l'application ne pourra pas fonctionner, c'est un peu excessif (AMHA).
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance aux DLLs
satellites, elle peut être supprimée très facilement grace à l'utilitaire
vblocal.exe de l'IPDK.
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
http://apisvb.europe.webmatrixhosting.net/
Patrick Philippot <patrick.philippot@mainsoft.xx> a écrit :
ng wrote:
La seule possibilité de faire des exe autonomes est d'inclure dans
l'exe toutes les DLLs du runtime et les OCX utilisés... Il existe des
utilitaires pour faire cela :
http://faq.vb.free.fr/index.php?question
Bonjour ng,
Merci pour ce lien, je ne connaissais pas ces produits.
Concernant le texte de la FAQ, il convient peut-être de modérer un peu
le propos:
"
...Si vous exécutez votre programme sur un poste qui ne possède pas
Visual Basic, celui-ci ne fonctionnera pas. En effet, les programmes
réalisés avec VB sont dépendants de toute une série de dll, elles-même
parfois dépendantes d'autres dll. Pour distribuer votre application,
utilisez l'Assistant Empaquetage & Déploiement (livré avec Visual
Basic) qui se chargera de rassembler toutes les dlls requises dans un
programme d'installation.
"
Rappelons que la seule DLL qui est toujours nécessaire, quelle que
soit la nature du code VB distribué et les options de compilation,
c'est MSVBVM60.DLL (ou MSVBVMxx.DLL pour les versions de VB pré VB6)
et que cette DLL est maintenant systématiquement distribuée avec le
système d'exploitation et avec de nombreux produits MS. Ce qui ne
veut pas dire qu'il ne faut pas vérifier sa présence à l'installation
de l'appli ou du composant.
Le texte de la FAQ devrait préciser que tout code VB6 est
*nécessairement* dépendant de MSVBVM60.DLL et éventuellement d'autres
DLLs en fonction des technologies et composants utilisés.
Mais dire que si on n'a pas VB6, l'application ne pourra pas
fonctionner, c'est un peu excessif (AMHA).
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance aux DLLs satellites, elle peut être supprimée très facilement grace à l'utilitaire vblocal.exe de l'IPDK.
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
Patrick Philippot a écrit :
ng wrote:
La seule possibilité de faire des exe autonomes est d'inclure dans l'exe toutes les DLLs du runtime et les OCX utilisés... Il existe des utilitaires pour faire cela :
http://faq.vb.free.fr/index.php?question
Bonjour ng,
Merci pour ce lien, je ne connaissais pas ces produits.
Concernant le texte de la FAQ, il convient peut-être de modérer un peu le propos:
" ...Si vous exécutez votre programme sur un poste qui ne possède pas Visual Basic, celui-ci ne fonctionnera pas. En effet, les programmes réalisés avec VB sont dépendants de toute une série de dll, elles-même parfois dépendantes d'autres dll. Pour distribuer votre application, utilisez l'Assistant Empaquetage & Déploiement (livré avec Visual Basic) qui se chargera de rassembler toutes les dlls requises dans un programme d'installation. "
Rappelons que la seule DLL qui est toujours nécessaire, quelle que soit la nature du code VB distribué et les options de compilation, c'est MSVBVM60.DLL (ou MSVBVMxx.DLL pour les versions de VB pré VB6) et que cette DLL est maintenant systématiquement distribuée avec le système d'exploitation et avec de nombreux produits MS. Ce qui ne veut pas dire qu'il ne faut pas vérifier sa présence à l'installation de l'appli ou du composant.
Le texte de la FAQ devrait préciser que tout code VB6 est *nécessairement* dépendant de MSVBVM60.DLL et éventuellement d'autres DLLs en fonction des technologies et composants utilisés.
Mais dire que si on n'a pas VB6, l'application ne pourra pas fonctionner, c'est un peu excessif (AMHA).
Christophe LEITIENNE
Bonjour,
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance aux
DLLs
satellites, elle peut être supprimée très facilement grace à l'utilitaire vblocal.exe de l'IPDK.
J'ai un problème avec ça d'ailleurs. Sur la page du IPDK, on ne parle que de VB6 SP3, 4 ou 5. Or je suis en SP6. Que dois-je faire ?
Christophe.
Bonjour,
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance aux
DLLs
satellites, elle peut être supprimée très facilement grace à l'utilitaire
vblocal.exe de l'IPDK.
J'ai un problème avec ça d'ailleurs. Sur la page du IPDK, on ne parle que de
VB6 SP3, 4 ou 5. Or je suis en SP6. Que dois-je faire ?
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance aux
DLLs
satellites, elle peut être supprimée très facilement grace à l'utilitaire vblocal.exe de l'IPDK.
J'ai un problème avec ça d'ailleurs. Sur la page du IPDK, on ne parle que de VB6 SP3, 4 ou 5. Or je suis en SP6. Que dois-je faire ?
Christophe.
ng
Salut,
Si tu veux simplement utiliser le VBLocal.exe, cela ne pose aucun problème et cela fonctionne avec les exe vb depuis VB5. Pour le reste il faudra bien faire attention à utiliser les dernières DLL du service pack.
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
Christophe LEITIENNE a écrit :
Bonjour,
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance aux DLLs satellites, elle peut être supprimée très facilement grace à l'utilitaire vblocal.exe de l'IPDK.
J'ai un problème avec ça d'ailleurs. Sur la page du IPDK, on ne parle que de VB6 SP3, 4 ou 5. Or je suis en SP6. Que dois-je faire ?
Christophe.
Salut,
Si tu veux simplement utiliser le VBLocal.exe, cela ne pose aucun problème
et cela fonctionne avec les exe vb depuis VB5. Pour le reste il faudra bien
faire attention à utiliser les dernières DLL du service pack.
--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
http://apisvb.europe.webmatrixhosting.net/
Christophe LEITIENNE
<c.leitienne@remove.this.and.invalid.bgpartners.fr.invalid> a écrit :
Bonjour,
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance
aux DLLs satellites, elle peut être supprimée très facilement grace
à l'utilitaire vblocal.exe de l'IPDK.
J'ai un problème avec ça d'ailleurs. Sur la page du IPDK, on ne parle
que de VB6 SP3, 4 ou 5. Or je suis en SP6. Que dois-je faire ?
Si tu veux simplement utiliser le VBLocal.exe, cela ne pose aucun problème et cela fonctionne avec les exe vb depuis VB5. Pour le reste il faudra bien faire attention à utiliser les dernières DLL du service pack.
-- Nicolas G. FAQ VB : http://faq.vb.free.fr API Guide : http://www.allapi.net Google Groups : http://groups.google.fr/ MZ-Tools : http://www.mztools.com/ http://apisvb.europe.webmatrixhosting.net/
Christophe LEITIENNE a écrit :
Bonjour,
En effet je suis d'accord avec ca. Pour ce qui est de la dépendance aux DLLs satellites, elle peut être supprimée très facilement grace à l'utilitaire vblocal.exe de l'IPDK.
J'ai un problème avec ça d'ailleurs. Sur la page du IPDK, on ne parle que de VB6 SP3, 4 ou 5. Or je suis en SP6. Que dois-je faire ?
Christophe.
Christophe LEITIENNE
> Si tu veux simplement utiliser le VBLocal.exe, cela ne pose aucun problème et cela fonctionne avec les exe vb depuis VB5. Pour le reste il faudra
bien
faire attention à utiliser les dernières DLL du service pack.
Ok, merci.
> Si tu veux simplement utiliser le VBLocal.exe, cela ne pose aucun problème
et cela fonctionne avec les exe vb depuis VB5. Pour le reste il faudra
bien
faire attention à utiliser les dernières DLL du service pack.
Merci pour toutes vos réponses. Si j'ai bien compris si je veux faire un exe autonome ne n'est pas forcément simple !!
Je comprends bien que si mon programme fait appel a plusieurs dll ou ocx il ne peut qu'être dépendant de ceux-ci, mais lorsque ce programme ne contient que du code et quelques formulaires (feuille) faut-il absolument la MSVBVM60.DLL quand même ??
Est il vraiment possible de faire un exe avec des formulaires qui soit vraiment autonome (que l'exe c'est tout) ?
L'assistant d'empactage crée en fait un install qui déploie l'application sur le poste, mais l'inconvénient est que l'on n'a aucune maitrise de ce qui est installé, et par expérience c'est une source d'énormes problèmes lorsque l'on distribue l'application.
Le mieux est toujours de connaitre exactement les éléments nécessaire et suffisant pour le fonctionnement de l'application et d'utiliser un installeur proffessionnel tel "WISE" , "InstallShield" etc...
Le hic chez les pros de la programmation est qu'il ne pense jamais à la mise en place de leur application (Ca aussi c'est de l'expérience ..), c'est dommage d'avoir de supers programmes et de ne pas pouvoir les utiliser sur d'autre machine.
En tout les cas merci beaucoup pour toutes les informations et les liens utiles.
Tout n'est pas toujours si simple !!!!
FRED87
Bonjour
Merci pour toutes vos réponses.
Si j'ai bien compris si je veux faire un exe
autonome ne n'est pas forcément simple !!
Je comprends bien que si mon programme fait appel
a plusieurs dll ou ocx il ne peut qu'être dépendant de
ceux-ci,
mais lorsque ce programme ne contient que du code et
quelques formulaires (feuille) faut-il absolument la
MSVBVM60.DLL quand même ??
Est il vraiment possible de faire un exe avec des
formulaires qui soit vraiment autonome (que l'exe c'est
tout) ?
L'assistant d'empactage crée en fait un install qui déploie
l'application sur le poste, mais l'inconvénient est que
l'on n'a aucune maitrise de ce qui est installé, et par
expérience
c'est une source d'énormes problèmes lorsque l'on distribue
l'application.
Le mieux est toujours de connaitre exactement les éléments
nécessaire et suffisant pour le fonctionnement de
l'application et d'utiliser un installeur proffessionnel
tel "WISE" , "InstallShield" etc...
Le hic chez les pros de la programmation est qu'il ne
pense jamais à la mise en place de leur application (Ca
aussi c'est de l'expérience ..), c'est dommage d'avoir de
supers programmes et de ne pas pouvoir les utiliser sur
d'autre machine.
En tout les cas merci beaucoup pour toutes les
informations et les liens utiles.
Merci pour toutes vos réponses. Si j'ai bien compris si je veux faire un exe autonome ne n'est pas forcément simple !!
Je comprends bien que si mon programme fait appel a plusieurs dll ou ocx il ne peut qu'être dépendant de ceux-ci, mais lorsque ce programme ne contient que du code et quelques formulaires (feuille) faut-il absolument la MSVBVM60.DLL quand même ??
Est il vraiment possible de faire un exe avec des formulaires qui soit vraiment autonome (que l'exe c'est tout) ?
L'assistant d'empactage crée en fait un install qui déploie l'application sur le poste, mais l'inconvénient est que l'on n'a aucune maitrise de ce qui est installé, et par expérience c'est une source d'énormes problèmes lorsque l'on distribue l'application.
Le mieux est toujours de connaitre exactement les éléments nécessaire et suffisant pour le fonctionnement de l'application et d'utiliser un installeur proffessionnel tel "WISE" , "InstallShield" etc...
Le hic chez les pros de la programmation est qu'il ne pense jamais à la mise en place de leur application (Ca aussi c'est de l'expérience ..), c'est dommage d'avoir de supers programmes et de ne pas pouvoir les utiliser sur d'autre machine.
En tout les cas merci beaucoup pour toutes les informations et les liens utiles.
Tout n'est pas toujours si simple !!!!
FRED87
Patrick Philippot
FRED87 wrote:
mais lorsque ce programme ne contient que du code et quelques formulaires (feuille) faut-il absolument la MSVBVM60.DLL quand même ??
Je répète (au risque d'être pesant, désolé si je radote):
**Aucune** entité de code développée en VB ne peut s'exécuter sans la présence sur le système de la runtime VB (MSVBVM60.DLL pour VB6). (pourquoi est-ce que je pense à Fernand Raynaud et au sketch des croissants d'un seul coup? :-)))) )
Les solutions d'empaquetage contournent le problème en ajoutant ce code à l'exe (comme ressource) et en le recréant dynamiquement au moment de l'exécution. C'est juste un artifice. Quant aux autres composants, l'avantage de leur isolation est le partage avec d'autres applications. C'est l'objectif.
Dans la programmation moderne, on fait justement tout pour éviter les gros EXE monolithiques qui doivent être entièrement recompilés et redistribués à chaque fois qu'une virgule change dans le code. Et je n'évoque même pas d'autres problèmes encore plus lourds pour les applications d'entreprise.
Le hic chez les pros de la programmation est qu'il ne pense jamais à la mise en place de leur application (Ca aussi c'est de l'expérience ..),
Si ce sont des pros, justement, il portent attention au problèmes d'installation.
Bon courage.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.fr
FRED87 wrote:
mais lorsque ce programme ne contient que du code et
quelques formulaires (feuille) faut-il absolument la
MSVBVM60.DLL quand même ??
Je répète (au risque d'être pesant, désolé si je radote):
**Aucune** entité de code développée en VB ne peut s'exécuter sans la
présence sur le système de la runtime VB (MSVBVM60.DLL pour VB6).
(pourquoi est-ce que je pense à Fernand Raynaud et au sketch des
croissants d'un seul coup? :-)))) )
Les solutions d'empaquetage contournent le problème en ajoutant ce code
à l'exe (comme ressource) et en le recréant dynamiquement au moment de
l'exécution. C'est juste un artifice. Quant aux autres composants,
l'avantage de leur isolation est le partage avec d'autres applications.
C'est l'objectif.
Dans la programmation moderne, on fait justement tout pour éviter les
gros EXE monolithiques qui doivent être entièrement recompilés et
redistribués à chaque fois qu'une virgule change dans le code. Et je
n'évoque même pas d'autres problèmes encore plus lourds pour les
applications d'entreprise.
Le hic chez les pros de la programmation est
qu'il ne pense jamais à la mise en place de leur
application (Ca aussi c'est de l'expérience ..),
Si ce sont des pros, justement, il portent attention au problèmes
d'installation.
Bon courage.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
mais lorsque ce programme ne contient que du code et quelques formulaires (feuille) faut-il absolument la MSVBVM60.DLL quand même ??
Je répète (au risque d'être pesant, désolé si je radote):
**Aucune** entité de code développée en VB ne peut s'exécuter sans la présence sur le système de la runtime VB (MSVBVM60.DLL pour VB6). (pourquoi est-ce que je pense à Fernand Raynaud et au sketch des croissants d'un seul coup? :-)))) )
Les solutions d'empaquetage contournent le problème en ajoutant ce code à l'exe (comme ressource) et en le recréant dynamiquement au moment de l'exécution. C'est juste un artifice. Quant aux autres composants, l'avantage de leur isolation est le partage avec d'autres applications. C'est l'objectif.
Dans la programmation moderne, on fait justement tout pour éviter les gros EXE monolithiques qui doivent être entièrement recompilés et redistribués à chaque fois qu'une virgule change dans le code. Et je n'évoque même pas d'autres problèmes encore plus lourds pour les applications d'entreprise.
Le hic chez les pros de la programmation est qu'il ne pense jamais à la mise en place de leur application (Ca aussi c'est de l'expérience ..),
Si ce sont des pros, justement, il portent attention au problèmes d'installation.
Bon courage.
-- Patrick Philippot - Microsoft MVP [.Net] MainSoft Consulting Services www.mainsoft.fr
