Bonjour,
je me demande comment compilé un programme VB en exécutable.
Bien sûr VB permet d'enregistrer son programme en EXE, mais il ya un problème de DLL si l'on n'a pas Visual Basic installé sur la machine.
Peut on compilé un programme VB avec sa base access (mon programme intérroge une base de donnée)?

La compilation en VB n'est pas une véritable compilation. Aucun programme visual basic ne saurait se passer des fameuses DLL...
 
(au fait... c'est "je me demande comment compilER" )

Oui désolé, je suis une grosse crotte en orthographe.
Pas de compilation avec DLL? Embêtant...
Et pareil pour Access? Pas moyen d'utiliser mon programme sans Access installé sur la machine?
 

Tu n'as qu'a filer les DLL avec ton exe, tout le monde fait ca!

Oui ben je crois que je vais être contraint...
Dommage, j'aurai voulu une install facile, enfin juste un exe.
Merci.

 
Pour access je pense que c'est possible de créer un petit soft indépendant, mais je sais pas comment...
 
Quelqu'un peut confirmer?

Assistant d'empaquetage et déploiement.
 
-> Tu chois ton projet et tu le laisses faire.
 
Il va te générer un programme d'install avec toutes les DLL (celles de VB et celles que tu utilises depuis le programme)
 
Par contre, l'install est merdique, et te demandras de rebooter en plein milieu, il faut alors relander l'install pour finir l'install.
 
Y'a des softs gratuits qui permettent de faire un install mieu.
 
Inno Setup par exemple.

Merci beaucoup MagicBuzz, je suis en train de regarder tout ça.

 
 
il peut le faire à la main, sa va aussi vite et c'est tout bénéfique :
 
- il compile son prog
- avec "depends", il regarde de quoi dépend son *.exe (Ocx, *.Dll,ect...)
- Il récupère le tout
- Il donne ensuite les fichiers en questions + l'*.exe...

 
 
tu ne connais pas la méthode, manifestement ??  
je vais donc détailler :
 
Démarrer > programmes > Microsoft visual Studio 6.0 > Outils Microsoft Visual Studio 6.0 > Depends
 
Tu arrive à quelques chose comme ça !
   
 
il aura tous les fichiers qui dépendent de son *.exe, (*.dll, *.ocx), il n'as plus qu'a les COPIER. Sur une disquette, ou un CD, il mets ses fichiers en questions + son programme compilé. c'est le principe utilisé, dans tous les CD. Eh oui !  
 
Si tu veux faire démarrer un programme, par un autorun, programme fait en VB, c'est cette méthode qu'est utilisé...l'exe, plus les fichier dont-ils dépends à sa racine...

le problème n'est pas que je connaisse pas, sinon je l'aurais dit explicitement
 
Ce qui m'intrigue, c'est pourquoi conseiller de le faire à la main alors que MagicBuzz a donné quelques bons éléments pour le faire faire par la machine.  Si j'ai un automate pour le faire et qu'il le fait bien, je vais pas prendre le temps de le faire à la main, ce qui prendrait forcément plus de temps.  Moi je donne mon exe, mes fichiers de données et basta

 
tu me rassure  !   personellement avec cette méthode, je ne pourris pas la Bdr et je vais plus vite que l'assistant !  

faut quand même que j'avoue un truc, je ne fais pratiquement jamais de package d'install, mon client a tout ce qu'il faut pour faire ça en interne

 
Ah tu vois, que cette merde d'empaquetage est merdique !  

non c'est pas ça
 
c'est juste que c'est une très grosse boîte qui doit gérer une bonne centaine d'applications internes écrites en différents langages et il y a un système de mise à jour plutôt uniforme et assez réussi pour s'occuper de tout ça
 
nous on s'en fout, on leur livre ce qui est utile et ils se débrouillent pour la distribution

D'autant plus qu'en cas de conflit de version de DLL, il faut mieu faire gérer ça par un programme que à ma main...
 
Le mieu étant pour ce qui est des DLL faisant elles-même référence à d'autres DLL ! Exemple avec MDAC. L'assistant de VB saura lesquelles distribuer, et lorsque la distribution est impossible "simplement", comme pour MSXML 3.0, il dit qu'il faut joindre l'install de ce programme, et l'installer avant d'installer le programme VB
 
A la main, on détecte pas ce genre de problèmes.

Merci pour toutes vos réponse.
Mais la base ACCESS ne peut pas être utilisé sans qu'il y est access d'installé sur la machine.
Moi ce que je souhaite c'est que mon programme puisse tourné sur n'importe quel machine même si access n'est pas installé...
Je pense que c'est impossible.
Ai je raison?  

 
Peut etre que je me plante, mais ta base Access, tu y accèdes comment à partir de VB? Via ODBC? Si c'est le cas, ca doit bien etre possible de faire cette install sans Access sur la machine, nan?

Dans ta base access, tu te sert que des tables/requêtes ou si tu te sert aussi de formulaire ?
 
Parceque si tu te sert pas des formulaires et autres trucs graphiques d'access, tu n'as pas besoin d'access sur la machine, juste d'une version à jour de MDAC

salut spir! conecernant ces fameux dll, effectivement il est possible de les connaitre facilement avec l'assitant d'empaketage de VB, cependant, si je peut te donner un sonseil, n'utilise pas cette m**** compile un setup bidon, au cours de ceci il te demande un repertoire ou il te met tous les fichiers non compréssé, c'est alors à ce momment la que je te conseille setup générator, je ne sais plus ci celui ci est gratuit, mais tu dois pouvoir l'essayer et ensuite l'acheter si il te plait ;x
si tu veux un exemple de paketages créés par ce setup: http://www.speedram.net tu y trouvera mon programme avec le setup créé par setup générator
 
Enjoy!

Perso, je préfère innoSetup, y'a un wizard pour VB qui est tout fait, et il est capable à partir du *.vbp de retrouver toutes les dépendances. Faut juste lui fournir l'exe compilé en plus, sinon ça marche pas
 
Par contre, ce que j'aime pas avec ces trucs à la noix, c'est que si tu as une plateforme de dev Windows 2000 US, à 99 contre 1, ça ne marchera pas quand tu vas l'installer sur un Windows 98 FR, pour cause de conflits de DLL (versions et langage) donc je préfère utiliser la grosse daube qu'est l'assistant de VB, qui met toutes les DLL nécessaires pour les différents environnements, sauf quand je connais à l'avance l'architecture logicielle des clients.
 
Par exemple, essaie de mettre les DLL de MSXML dans un projet VB, tu vas pleurer. L'assistant VB au moins, il t'indique qu'il n'est pas capable de les intégrer dans le setup, et qu'il faut redistribuer la version complète (téléchargeable depuis le site de M$) car la DLL est trop dépendante de la plateforme pour être intégrer dans un install comme ça.
 
Donc je pense que même si on n'utilise pas forcément l'assistant de VB pour l'install final, une première passe avec permettra de lever les loups.
 
Idem pour CDONTS : Entre NT4 et 2000, c'est pas la même DLL, et elles ne sont pas compatibles. Sous Windows 9x, elle est carrément pas supportée. Donc on a vite des problèmes, et l'assistant de VB à l'avantage de le dire avant d'envoyer au pressage les 50 000 copies du logiciel

 
c'est vrai que vu comme ca c'est different, j'avue ne pas avoir encore rencontré ce probleme, j'ai constaté qu'un dll absent windows le cherche en premier dans le repertoire de l'exe, puis system, win etc.. donc dans mon setup je met tout dans le meme repertoire, il ne me semble pas avoir eprouvé de problemes jusqu'a présent.. de plus plus de conflit de version.. le prog utilise SON dll.. mais il est vrai que ca peut paraitre bourin

Bah ouais mais disons qu'en VB, le but du jeu c'est d'utiliser un max de dll systèmes pour pas avoir à faire les siennes (sinon, autant passer au C, qui sera plus puissant et plus rapide )

oui j'y songeai tres fortement...

 
non tu peux rendre ta base autonome cad qu'elle n'aura pas besoin d'acces pour se lancer. TU as besoin pour cela de la version developper d'office ou tu trouveras le run time d'access.
 
voila en esperant t'avoir aidé.

 
Salut,  
 
Peux tu me dire ou ce trouve cette fonction dans VB ?

Dans le menu Démarrer, dans le groupe de programmes de VB

Merci beaucoup  

Access n'est pas nécessaire pour accéder à ta bdd, c'est ton programme qui l'attaquera directement, même si Access ou Office n'est pas installé sur la machine cliente.