Comment définissez-vous une variable de style Makefile dans une solution à utiliser dans plusieurs projets (VS 2008)?

Question

Je travaille dans une solution Visual Studio 2008 avec plusieurs projets C# et quelques projets C++ et je veux utiliser des événements post-construction pour exécuter des outils de ligne de commande fournisseurs tiers. Ces événements de post-construction sont nécessaires dans plusieurs projets.

Je peux coder en dur les noms de chemin et d'autres fichiers nécessaires sur la ligne de commande, mais je préférerais vraiment quelque chose de plus flexible. Peut-être:

$ (ToolsDir) $ \ (PackageBuilder) $ (ThirdPartyDllFolder) $ (SharedOutputFolder)

Lorsque j'ai développé pour UNIX et utilisé makefile pour effectuer construit, je suis en mesure de définir une variable dans un niveau élevé makefile et hérité par makefiles enfants. De cette façon, je pourrais avoir toutes les sorties aller à un endroit particulier, ou chercher dans un endroit particulier pour une bibliothèque, etc.

Existe-t-il une chose équivalente qui peut être faite en utilisant des solutions Visual Studio, telles que je pourrais définir quelque chose comme une variable d'environnement et ensuite le référencer dans un événement de post-construction au niveau du projet?

EDIT: J'utilise actuellement des variables d'environnement Windows, mais je préférerais quelque chose qui ne nécessite pas d'installation en dehors du simple téléchargement du code et de sa construction.

Answer 1

Avez-vous considéré les variables d'environnement dans Windows? Je sais que ce n'est pas exactement la même chose, mais vous pouvez les définir avec un fichier batch et exécuter ce fichier batch après la construction.

Answer 2

J'ai eu un problème similaire il y a un certain temps. Ma première «solution» consistait à créer un outil qui était construit et exécuté lorsqu'un développeur obtenait le premier «get» du référentiel. Ce n'était pas joli et était une étape supplémentaire - mais seulement une fois. J'ai abandonné cela et maintenant nous avons une autre méthode. Nous plaçons des outils tiers dans un dépôt svn (différent de notre source) et demandons une hiérarchie et un nom spécifiques pour l'endroit où ce référentiel vit par rapport à la racine de notre base de code. De cette façon, nous pouvons utiliser des chemins relatifs avec confiance dans nos étapes de post-construction ou d'autres parties. Je suis d'accord que c'est un peu un point faible dans les outils de construction MS.