Discussion :

[jmfmarques]

Attendons le chef (Thierry). Microsoft Office est une chose, ses moteurs peuvent en être une autre (moindre mais nécessaire, peut-être... sais pas )

[MGD_Software]

Et si tu essayais tout bêtement de faire un package avec l'installateur intégré de VB? tous ceux que j'ai réalisés (deux petites centaines d'applis différentes au minimum) avec le générateur de packages de VB se sont toujours bien comportés. Bon c'est vrai qu'il a pas mal de tares, mais au moins l'intall se passe correctement dans 90% des cas. Les problèmes que j'ai eu se passaient sur des windows japonais ou coréens, ou encore sur des PC dont le propriétaire a avoué avoir bricolé la base de registre après l'install.

Par contre, aussi bien avec InstallShield que Wise (et je ne parlepas de NSI où il faut tout faire à la main!), de temps en temps il manque un composant, ou bien l'installateur ne remplace pas une DLL plus ancienne (ça ne te rappelle rien ?), ou bien la base de registre n'est pas correctement mise à jour, etc.

Si avec le package VB il y a toujours un pb avec msvbvm60, c'est que tu as vraiment un problème avec les machines, car les DLL du PC de développement sont recopiées sur le PC cible.

Plusieurs choses à vérifier :
1. le VB dont tu te sert a-t-il la dernière mise à jour (service pack 6)
2. As-tu essayé d'installer le kit runtime VB6 (VBRUN60.EXE) sur la machine cible APRES l'installation. Normalement cela résoud pratiquement tous les problèmes de version, car il remplace tous les composants de base de VB. Ce qui prouverait que c'est bien un problème de version.
3. En supprimant le msvbvm60.dll déjà présent sur la machine, y est-il de nouveau après installation ? et dans ce cas l'appli marche-t-elle? Dans l'affirmative, cela prouverait que le package ne remplace pas l'ancienne version. Normalement on DOIT trouver après installation les mêmes dll que sur la machine de développement, ou des plus récentes (ces dernières ne sont pas remplacées, mais normalement le package d'install doit signaler la présence d'une version plus récente et demander s'il doit la remplacer ou la garder).

Bon courage.

P.S. : un moyen très pratique pour tester les installs sur différentes plateformes est d'utiliser une machine virtuelle (WmWare ou Microsoft Virtual PC). On revient à la version précédente ou un "snapshot" en moins de 30 secondes, et il n'est pas nécessaire d'avoir plusieurs PC ou disques durs. On peut même faire tourner Linux sous Windows !. Chaque machine utilise un fichier (de plusieurs Go qd même!), mais on passe en une minute d'un XP anglais à un Win2000 chinois ou un Win98 allemand, etc. Génial pour tester les packages.

[ThierryAIM]

Bon, là franchement je vois pas d'ou peut provenir l'erreur

je te propose :

1) de tester avec les fichiers du runtime VB6, ici

2) tu m'envoies ton appli (complète), je teste une install avec InnoSetup

car j'ai jamais vu ce phénomène

[MGD_Software]

Je rajoute quelque chose après avoir lu les contribs quasi simultanées à la mienne..

Si tu utilises une base de données Access (DAO ou ADODB), alors sors ton mouchoir avec InstallShield ou Wise ! L'enregistrement du moteur de base de données Jet (celui d'Access) est une vraie galère. Il est impératif que les DLL DAO ou ADODB soient dans un répertoire très spécifique (C:\Program Files\Fichiers communs\Microsoft Shared\DAO), et il doit exister des clés très spécifiques dans la base de registre avec des CLSID spécifiques...

J'ai épluché l'installateur de vb (Setup1) dont Microsoft, dans un moment d'égarement, a distribué les sources, et même en reproduisant rigoureusement la procédure d'enregistrement du moteur bdd, je n'arrive pas à l'installer correctement. Du coup je me rabats sur le Setup de VB, qui lui marche bien.

Si quelqu'un connaît le truc pour installer DAO avec Wise, je suis très preneur!

[ThierryAIM]

J'ai épluché l'installateur de vb (Setup1) dont Microsoft, dans un moment d'égarement, a distribué les sources,

Livrée avec VB6, et modifiable à façon, selon µS
Y'a plus de boulot pour faire un Setup qui marche correctement(quand on veut lui faire faire autre chose que la base) que pour développer l'appli

Avec Wise, je sais pas, mais avec Inno Setup, y'a aucun soucis
Depuis le temps que je distribue des applis avec DAO, puis ADO

Faut juste pas en oublier des morceaux

[AlainTech]

avec Inno Setup, y'a aucun soucis

Idem pour moi.

J'ai même fait un "réparateur" de DAO/Jet 3.51 avec InnoSetup

Pour ceux que ça intéresse, il est disponible là:
http://vb.developpez.com/outils/down...tallDAO350.exe

[MGD_Software]

J'ai même fait un "réparateur" de DAO/Jet 3.51 avec InnoSetup

Pour ceux que ça intéresse, il est disponible là:
http://vb.developpez.com/outils/down...tallDAO350.exe

C'est téléchargé !
Y'aurait le même (ou les sources) pour DAO 3.6 ? Parce là je suis très très intéressé !

Je ne connais pas InnoSetup. Ca se trouve où et à combien ?
Sait-il aller fouiner dans le fichier projet pour trouver tout ce qu'il faut (à part bien sûr les fichiers de données), y compris les composants DA0, les activeX des aides en HTML compilé, etc. , ou faut-il entrer à la main tous les composants nécessaires, comme NullSoft Installer ?

c'est le "faut juste pas en oublier des morceaux" qui m'inquièrte un peu. S'il faut utiliser l'inspecteur de dépendances fourni avec Visual Studio, bonjour le boulot ! Et j'ai déjà fait une fois l'expérience de 1000 CD à regraver parce qu'il manquait une DLL de rien du tout, je ne tiens pas à la refaire.

[AlainTech]

http://www.jrsoftware.org/isinfo.php

C'est OpenSource, donc gratuit.

Je n'ai pas fait l'équivalent pour DAO 3.6 car jamais eu besoin.
Ma source InnoSetup ne t'aiderait que peu (quoique) car tout est dans le fait de mettre les bons fichiers dans les bons répertoires.
Dès que j'ai un peu de temps, je poste la source du DAO 3.51.

[MGD_Software]

tout est dans le fait de mettre les bons fichiers dans les bons répertoires.

C'est pas tout à fait vrai. Il faut aussi que la base de registre soit correctement renseignée. Je viens d'en faire l'amère expérience avec Wise et DAO 3.6, justement.

[AlainTech]

tout est dans le fait de mettre les bons fichiers dans les bons répertoires.

C'est pas tout à fait vrai. Il faut aussi que la base de registre soit correctement renseignée. Je viens d'en faire l'amère expérience avec Wise et DAO 3.6, justement.

Je parlais des répertoires dans lesquels JE mets les fichiers pour l'installateur.
Pour un programme "normal", j'en crée 4:

• Fichiers du programme ne devant pas être enregistrés (regsvr)
• Fichiers du programme (dll et OCX) devant être enregistrés (si nécessaire)
• Fichiers "système" devant être enregistrés
• Fichiers "système" ne devant pas être enregistrés

C'est la raison pour laquelle je dis que ma source éclaire peu sur ce qu'elle fait si on ne connait pas le contenu des dits répertoires.

[MGD_Software]

Bon, je veux bien pour la copie des fichiers dans des emplacmeents ad hoc.

Ce qui me titille, cest comment avec ça l'installateur fait il pour enregistrer les infos dans la base de registre ?

Dans le Setup de Microsoft (module basSetup1, procédure RegisterDAO), on trouve l'enregistrement des clés suivantes dans HKEY_CLASSES_ROOT :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    Clé = CLSID\{F7A9C6E0-EFF2-101A-8185-00DD01108C6B}
    Valeur = "OLE 2.0 Link"
 
    Clé = CLSID\{F7A9C6E0-EFF2-101A-8185-00DD01108C6B}\InprocHandler
    Valeur = "ole2.dll"
 
    Clé = CLSID\{F7A9C6E0-EFF2-101A-8185-00DD01108C6B}\ProgID
    Valeur = "Access.OLE2Link"

Ca ne s'invente pas ! Et j'ai dû en louper, car même en les créantà la main avec l'éditeur de base de registre, Jet continue à ne pas fonctionner, même après un redémarrage.

Il faut les rentrer à la main dans Inno Setup, ou il trouve tout seul ?

[AlainTech]

Voici ma source pour le DAO 3.51.
A renommer en .iss pour povoir l'utiliser dans InnoSetup.

Pour les clés de registre, je pense (mais n'en suis pas du tout certain) que le regsvr32 s'en charge.

Je vais vérifier et te tiendrai au courant.