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.
