Fichiers de projet Vb6 et source sûre

Question

Une partie de l'application sur laquelle je travaille est une ancienne application de formulaires Windows Vb6. Tous les fichiers du projet sont sous contrôle de source (VSS) sauf le fichier de projet Vb6. De ce que je peux établir à partir des autres développeurs travaillant sur le projet, la raison en est que les composants com utilisés dans les projets ont des références différentes sur chaque machine de développement. Je veux déplacer les fichiers de projet dans VSS de sorte que lorsque des fichiers sont ajoutés au projet, ils peuvent être mis à jour dans les fichiers de projet et d'autres développeurs (et surtout un script de construction automatisé).

Est-ce que quelqu'un sait si/comment je peux réaliser cela de manière à ne pas corrompre les références à d'autres composants COM sur différentes machines de développement?

Answer 1

Je ne suis pas d'accord avec vos collègues. Si chaque développeur a besoin de références différentes sur sa machine, je suis prêt à parier que vous avez un usage étrange des types COM en cours. Vous avez probablement des types CoClass et des types d'interface compilés dans vos DLL. Il s'agit de séparer l'interface de l'implémentation (même si VB6 fait de son mieux pour annuler cela en créant des interfaces par défaut pour chaque CoClass sans vous en parler). Déplacez vos types dans une bibliothèque de type TLB et référencez-le dans vos projets. Laissez l'enregistrement COM sur chaque machine gérer quelles classes spécifiques sont instanciées; c'est ce qu'il est là pour.

Si votre équipe est aux prises avec des références COM, c'est que quelque chose de plus profond est faux.

Answer 2

Longue histoire courte, non.

Le problème réel est que les développeurs n'obtiennent pas leurs composants COM du même endroit, soit parce qu'ils les compilent localement, soit parce qu'ils obtiennent différentes versions du même composant. Si les objets COM ne sont pas en développement constant, la vraie solution est que tous les développeurs installent la même version des composants dont ils ont besoin.

Answer 3

Vous devez gérer une norme qui décrit la structure de votre dossier de projets de développement. Par exemple, je recommande toujours de créer un substitue lecteur SUBST. Tels que SUBST H: C: \ DEV_ \ APP \ Visual Studio 2008. Cela permet au développeur de mettre ses choses là où il a besoin. Dans ce "nouveau" lecteur, je recommande un dossier "système". Chaque objet COM et dépendances sont placés dans un sous-dossier. Tous les projets référencent les objets COM uniquement à partir de H:/System /. Différentes versions COM entrent dans un nouveau avec la version dans le cadre du nom du dossier. Par exemple, C: \ DEV_ \ APP \ DEV \ SYSTEM \ Iocomp et C: \ DEV_ \ APP \ DEV \ SYSTEM \ Iocomp2.

(Ne pas oublier d'enregistrer les objets COM du bon chemin, le « nouveau » disque.)

J'utilise un fichier batch au démarrage pour définir quatre unités de développement differnt. La bonne chose à propos de l'utilisation de SUBST, est que vous pouvez vérifier dans un autre dossier, puis créer un lecteur "H" pour ce dossier et tout fonctionne. J'utilise cette technique depuis 1996 à très bon effet. Je n'ai jamais aucun problème. Le plus difficile est de faire connaître la technique aux autres.