Citation:
ok mais justement si c'est bien rangé c est simple enfin c'est mon point de vue pour retrouver mes petits.
Moi, je trouve qu'avoir le répertoire system32 avec des milliers de dll copiées à l'arrache (sans prendre la peine de vérifier qu'une version plus récente y est déjà, et sans ajouter au compteur d'utilisation de cette dll par une application dans la base de registre) ou avoir une variable d'environnement PATH avec ces centaines de chemins vers des répertoires de projet qui n'existent plus ou qui ne sont valides que sur la machine d'un des dizaines de développeurs du projet; c'est très très moyen. :aie:
Votre configuration est le cas typique d'un projet Windows.
Imaginez que vous deviez copier à la main la Dll après chacune de ses générations dans system32. :roll:
Imaginez que vous deviez changer votre variable PATH à chaque nouveau projet, et sur les machines de tous les développeurs. :roll:
A votre configuration typique, il existe au moins une solution des plus simples et élégantes.
Je n'ai plus de VC++6.0 depuis bien des années. Il est obsolète depuis au moins 12 ans et plus supporté par M$ depuis belles lurettes.
Sur les versions récentes de Visual Studio, on peut définir des dépendances entre des projets d'une solution Visual Studio. VS analyse le type des projets et copie automatiquement le résultat de la compilation d'un projet Dll (donc la Dll en Debug ou en Release, c'est selon) dans le répertoire utilisé par le projet dépendant pour y stocker l'exécutable.
Donc la manipulation se résume à indiquer à VS, via des commandes dans le menu contextuel, que votre projet exe dépend du projet Dll. ET C'EST TOUT.
Si VC++6.0 n'implémente pas les dépendances de projets (ce qui m'étonnerais, de mémoire) ou que son mécanisme de dépendance ne sert qu'a inférer l'ordre de compilations des projets, il reste une solution de compensation pour arriver au même niveau de fonctionnalité.
Les projets VC++6.0 disposent de la fonctionnalité de BuildEvent.
C'est simplement la possibilité d'indiquer des commandes CMD(~ shell d'*nix)
juste avant et juste après la génération/compilation du projet.
Vous pouvez donc facilement ajouter une commande de copie de la Dll générée en Post-Build Event de votre projet de Dll ou en Pré|Post-Build Event de votre projet de l'application.
Dans ces "scripts", vous disposez de toutes les "variables" nécessaire pour qu'ils soient simples et résistants aux changements/fluctuations de configuration. (Debug vs. Release, chemin vers le répertoire du projet, de la solution, nom des fichiers générés etc.)
La copie systématique d'une Dll en fin de compilation dans un répertoire d'un autres projets de la solution se fait en UNE ligne.(et cela quelque soit la configuration Debug/Release ou le répertoire de la solution)
Donc mon approche est bien une solution de feignant atteint au dernier stade d'Alzheimer.
C'est aussi l'approche implémentée par les versions récentes de VS (quand il est utilisé correctement).:mrgreen:
Citation:
Après je veux juste pouvoir exécuter le hello dans VC et que ca marche sans déplacer cette fichu dll.
Moi, c'est mieux, c'est VS qui déplace la dernière version de la Dll, et la bonne (Debug/Release), à l'endroit qui va bien.
Citation:
Je note pour les MSI je suppose que cela correspond a un package avec les instruction d'install comme les rpm/deb dans le monde *nix.
Tout à fait.
En plus, les outils de créations de MSI qu'y s'intègrent à VS savent récupérer ces informations de dépendances et s'en servir pour générer un MSI avec toutes les Dll nécessaires.
Citation:
Et si c'est conseillé de mettre la dll avec l exe ok.
Pour les Dll non système, oui, c'est la règle.
Citation:
Pour le déploiement je verrais plus tard.
Vous vous diriger vers le syndrome "ça marche sur ma machine mais nulle part ailleurs". Le coût de la mise en place d'un projet de génération d'un MSI est quasi nul (sauf pour la prise en main de l'outil, mais il sera de toute façon nécessaire).
Citation:
Moi cela me va mais ca c'est pour la phase d'install je verrais ca dans plusieurs mois à mon avis
Ce n’est pas très "Agile" comme approche.
Il faut toujours tester très tôt dans le processus de développement et le packaging est nécessaire (et coûte quasi rien).
Pensez à utiliser VS2010 à la place de VC++6.0. Si vous n'utilisez pas les MFC, la version gratuite de VS2010, VS2010 Express est largement suffisante.
si votre code VC++6.0 est de bonne qualité, il migrera facilement en VC++2010.
Essayez, cela ne coute qu'un Dll de la version Express ou d'une version d'évaluation de VS2010.
Utilisez les méthodes éprouvées que je vous indique, cela permettra une bien meilleure intégration avec le reste des outils de l'écosystème VS.
