Wie definieren Sie eine Variable im Makefile-Stil in einer Lösung, die in mehreren Projekten verwendet werden soll (VS 2008)?

Question

Ich arbeite in einer Visual Studio 2008-Lösung mit mehreren C# -Projekten und einigen C++ - Projekten und möchte Post-Build-Ereignisse verwenden, um einige Befehlszeilenprogramme von Drittanbietern auszuführen. Diese Post-Build-Ereignisse werden in mehreren Projekten benötigt.

Ich kann die Pfadnamen und andere Dateien, die auf der Befehlszeile benötigt werden, hart codieren, aber ich würde wirklich etwas flexibleres bevorzugen. Vielleicht:

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

Wenn ich für UNIX entwickelt und verwendet Makefiles ausführen baut, konnte ich eine Variable in einem hohen Niveau definieren Makefile und haben es von Kindern Makefiles geerbt. Auf diese Weise könnte ich alle Ausgaben an einen bestimmten Ort gehen lassen oder an einer bestimmten Stelle nach einer Bibliothek usw. suchen.

Gibt es eine äquivalente Sache, die mit Visual Studio-Lösungen durchgeführt werden kann, die ich definieren könnte so etwas wie eine Umgebungsvariable und dann Referenz in einem Post-Build-Event auf Projektebene?

EDIT: Ich verwende Windows-Umgebungsvariablen im Moment, würde aber etwas bevorzugen, das keine Einrichtung außerhalb nur Herunterladen des Codes und den Aufbau benötigt.

Answer 1

Haben Sie Umgebungsvariablen in Windows berücksichtigt? Ich weiß, dass es nicht genau dasselbe ist, aber Sie könnten sie mit einer Batch-Datei einstellen und diese Batch-Datei nach dem Build ausführen.

Answer 2

Ich hatte eine ähnliche Frage vor einer Weile. Meine erste "Lösung" bestand darin, ein Tool zu erstellen, das erstellt und ausgeführt wurde, als ein Entwickler das erste "Holen" aus dem Repository erhielt. Es war nicht schön und war ein weiterer Schritt - aber nur einmal.

Ich habe das aufgegeben und jetzt haben wir eine andere Methode. Wir fügen Third-Part-Tools in ein Svn-Repository ein (ein anderes als unsere Quelle) und benötigen eine spezifische Hierarchie und einen Namen für den Speicherort des Repositorys im Verhältnis zum Stamm unserer Codebasis. Auf diese Weise können wir relative Pfade in unseren Post-Build-Schritten oder anderen Teilen vertrauensvoll verwenden.

Ich stimme zu, dass dies ein bisschen eine Schwäche in den MS Build-Tools ist.