Discussion :

[Calade]

Bonjour,

Je suis à la retraite et travaille donc maintenant exclusivement pour moi (VB6 SP6 sur XP SP3).

Je possède une trentaine de DLL et OCX de mon cru et que j'utilise régulièrement dans mes applis.
Jusqu'à une date récente je travaillais en mode Compatibilité Binaire. Mais à chaque compilation (qui est déjà normalement assez fastidieuse et où il faut aussi respecter un ordre précis), j'avais des problèmes de compatibilité que je ne découvrais qu'au moment d'exécuter une appli et qui m'obligeait à tout recompiler (ou presque). Résultat des courses je passais une bonne 1/2 journée à chaque fois sans parler de l'énervement.

Puis j'ai découvert sur je ne sais plus quel site l'option "Compatibilité des Projets" avec le nom de ma DLL/OCX dans le champ en-dessous. Là énorme gain de temps, si je dois bien entendu tout recompiler, je n'ai plus de problèmes et tout fonctionne à la 1ère recompil'. Par contre, au niveau des tests, c'est la galère.
Une appli A utilise une DLL D et un OCX O qui lui même utilise la DLL D, dans ce type de compatibilité, je suis obligé de tout monter dans un VBG (qui peut vite devenir énorme), sinon je ne peux rien faire. Si pour les essais j'essaie de mettre "Pas de compatibilité", pas moyen de tester les modifs (il continue d'utiliser la version enregistré sans tenir compte des références.

J'ai donc plusieurs question (désolé).
- La doc' ne m'ayant pas trop éclairé, quel est le meilleur mode de compatibilité pour travailler.
- Existe t'il un utilitaire (genre de batch) permettant de recompiler l'intégralité de mon "système" sans tout faire à la main.

Je précise que mes EXE (une quinzaine dont certains assez gros pour un particulier et que j'utilise tous les jours) sont tous redispatchés par COPY sous C:\Program Files (pour obéir à la mode Windows !). Tandis que les DLL et autres OCX (la recompilation les enregistrant en même temps) sont utilisés dans leur répertoire d'origine (avec leur .VBP).
D'où une autre question. Peut-être devrais-je les déplacer vers un répertoire autre et de pouvoir travailler tranquillement sur elles en même temps.
J'ajoute en outre que je possède 2 DLL qui possèdent une foultitude de fonctions génériques pour l'une et exclusivement relatives à SQL pour l'autre ainsi qu'un OCX contenant un certain nombre de contrôles (y compris redéfinissant certains OCX natifs de VB6) et que j'utilise absolument partout (surtout pour la 1ère DLL MAIS qui est elle totalement autonome (aucune référence personnelle ni OCX perso'). Alors si je devais en venir à déplacer mes DLL et OCX y a t'il un moyen de le faire en les réenregistrant en même temps ?

J'aimerais éviter d'avoir une installation à chaque fois, car pour n'avoir qu'un seul ordi cela me parait un peu lourd.

Voilà, si quelqu'un pouvait me conseiller cela serait sympa.
Merci d'avance.

Calade.

[DarkVader]

Bonjour,
Seule la compatibilité binaire assure le fonctionnement des applications dépendantes précédemment compilées.
Elle ne supporte pas la moindre modification d'un prototype ou la suppression d'une procédure exposée.
Il est fort probable que vous ayez reçu un message concernant une modification de ce type
et que votre réponse n'ait pas été d'ignorer les changements.

Je vous conseille fortement d'installer la MSDN (en téléchargement sur ce site) et de faire une recherche sur "compatibilité binaire".

Concernant la compilation par lots, il est possible de la réaliser en ligne de commande ou écrire un addin spécifique en référençant vb6ext.olb.

[Calade]

Merci pour votre réponse.

Pour faire court, je compile mes DLL/OCX en mode compatibilité binaire.
A ce moment mes applis les utilisant référencent la version dans le dossier de test.

Si je COPIE ces DLL/OCX dans un autre dossier (style \Windows\System32 ou équivalent) ET que je référence cette copie au moment de la compilation des EXE, je devrais être tranquille si je référence la version dans le dossier de test lors d'améliorations futures ?

Et si je fais une copie à l'aide de InnoSetup (avec enregistrement bien sur), cela devrait marcher ?