NAnt Best Practices [geschlossen]

Ich kenne keinen veröffentlichten Styleguide, aber ich kann meine Erfahrung teilen. Sie können viele der in anderen Programmierumgebungen verwendeten Techniken verwenden, z. B. um den Code modular zu gestalten und ihn auf mehrere Dateien aufzuteilen. In der Umgebung, die ich eingerichtet habe, ist jedes Projekt so angelegt: "[ProjectName] \ Common" enthält eine allgemeine Builddatei, die mit fast allen meinen Projekten verknüpft ist. Ich habe auch eine Reihe von gemeinsamen Subversion-Zielen in einer Datei gespeichert. Das Unterverzeichnis "Common" ist eigentlich ein svn: external, sodass es automatisch über mehrere Projekte hinweg synchronisiert wird. In der Datei Common.build gibt es viele Umgebungseigenschaften sowie einige wiederverwendbare Dateigruppen, einige wiederverwendbare Ziele und ein "StartUp" -Ziel, das von jedem "StartUp" -Ziel eines Projekts verwendet wird.

"[ProjectName] \ Project.build" enthält alle projektspezifischen Eigenschaften und Dateigruppen, von denen einige die Einstellungen von Common.build überschreiben. Diese Datei enthält auch ein "StartUp" -Ziel, das einige Laufzeiteinstellungen wie Assemblyversionsinformationen und abhängige Pfade einrichtet. Es führt auch das "Startup" -Ziel von Common.build aus. Diese Datei enthält die Common.build-Datei.

"[ProjectName] [AssemblyName] .build" enthält alle für eine einzelne Assembly spezifischen Einstellungen und Ziele. Diese Datei enthält das Project.build, das wiederum das Common.build enthält.

Diese Hierarchie funktioniert gut in unserer Situation, in der wir eine Stammversion und mehrere Zweigversionen eines Produkts auf einem Continuous Integration Server erstellen. Wie es jetzt aussieht, sind die einzigen Unterschiede zwischen den Skripten zum Erstellen der Stammversion und einem der Zweige nur eine Handvoll Zeilen.