Utilisation de NAnt et Ivy pour construire un projet VB6

Question

Je travaille sur un système d'intégration continue pour les applications .Net et VB6 utilisant Subversion, CruiseControl, NAnt et Ivy.

Le côté .Net n'est pas trop un problème, mais j'ai besoin d'un peu d'orientation avec le côté VB6 des choses, plus du côté 'DLL-enfer' des choses!

Mon installation actuelle obtient tous les fichiers dépendants pour mon système VB6, comme prévu et construit les divers projets dans ok. MAIS ... il utilise des DLL qui sont déjà enregistrées sur mon PC, et pas celles de mon dossier Lib, qui est où je résous mes dépendances de Ivy. Je peux contourner ce problème en enregistrant les DLL téléchargées après qu'Ivy les a résolu, ce qui signifie que le fichier de projet peut être pointé vers le dossier Lib local; mais je veux que mon script NAnt le fasse automatiquement, puis désenregistre-les automatiquement une fois le processus de construction terminé, afin que le prochain projet puisse faire la même chose.

Ce que je pense que je besoin d'aide, est la possibilité d'avoir Ivy me donner une liste des dépendances de projet ...

Par exemple, si je suis la construction du projet X, qui dépend des projets A, B et C, alors si je pouvais donner une commande à Ivy qui donnerait une liste comme A, B, C alors je peux les passer à un autre processus Cible pour les enregistrer/les annuler à leur tour ...

avoir un sens? Est-ce possible et suis-je en train de regarder cela de la bonne façon? Ou y a-t-il un meilleur moyen? Mes excuses, c'est que j'ai fait le tour des maisons pour expliquer cela ... !!

Answer 1

J'ai trouvé la réponse moi-même; Au lieu d'utiliser Ivy pour essayer de générer une liste de dépendances pour moi à la demande, j'ai pensé que j'utiliserais le système de fichiers pour me donner cette même liste, comme Ivy a fait son travail en résolvant les dépendances pour moi, résultant dans un dossier 'lib' plein de fichiers .dll ...

Tout ce que j'ai fait, est obtenir une liste des fichiers .dll dans ce dossier lib, les stocker dans une propriété (variable), puis reculer à travers cette même propriété en enregistrant/désenregistrant le cas échéant.

Simple vraiment ..!

Answer 2

Nous conservons les références de projet dans des fichiers REF séparés à côté de nos fichiers VBP et nous utilisons un outil personnalisé pour "réparer" les VBP lors de la compilation. Notre processus de construction est grandement inspiré de this page (The Way We Work) et nos fichiers REF sont des artefacts directs de la structure qu'il décrit. De la façon dont nous travaillons, vous pouvez suivre un lien vers L.J. Johnson's Take Control of Your Build Cycle pour un utilitaire qui fait la même "correction" sans fichiers externes. Fondamentalement, le correctif doit utiliser tlbinfo pour extraire LIBID de l'exécutable (OCX/DLL) et remplacer complètement le guid de la référence dans le fichier VBP. Une fois que cette procédure pas si compliquée est utilisée, cela n'a pas d'importance si vous utilisez une compatibilité binaire ou de projet pour vos projets. En outre, si vous effectuez des générations complètes, aucune des OCX/DLL précédentes ne doit être enregistrée.

Answer 3

Visual Build Pro est recommandé dans ce answer. Les autres réponses valent aussi le coup d'oeil.