.NET Build Systeme
Erich Eichinger
Hi all,
Nachdem ich mich gerade wieder mal 2 Tage mit NAnt herumgeschlagen habe: Wie sind eure Erfahrungen mit alternativen Build Systemen im .NET Bereich?
tx,
Erich
Alexander Groß
Hallo Erich,
ich bin vor einigen Wochen auf Rake umgestiegen und mit dieser Entscheidung sehr zufrieden. Das Build Script ist im Projekt auf ungefähr ein Drittel geschrumpft und leserlicher.
Ich hab das Skript bei GitHub eingestellt wenn du es dir anschauen möchtest:
http://github.com/agross/rake-me/tree/master
Hinweis: Das rakefile ist 1:1 aus dem Projekt übernommen.
Wer F# lernen möchte kann sich FAKE – F# Make von Steffen Forkmann anschauen.
Beste Grüße,
Alex
--~--~---------~--~----~------------~-------~--~----~
Sie erhalten diese Nachricht, weil Sie Mitglied sind von Google Groups-Gruppe
"altnetde".
Für das Erstellen von Beiträgen in dieser Gruppe senden Sie eine E-Mail
an altn...@googlegroups.com
Um sich von dieser Gruppe abzumelden, senden Sie eine E-Mail an
altnetde+u...@googlegroups.com
Weitere Optionen finden Sie in dieser Gruppe unter http://groups.google.com/group/altnetde?hl=de
-~----------~----~----~----~------~----~------~--~---
Laurin Stoll
Pah... wer will das schon?
Nein echt... nant, rake ... ich finde sogar TFS Build Server kann man
in eine Tonne kippen. Wer Final Builder angeschaut hat und auch mal
verwendet hat - der will nichts anderes mehr. Auch als programmierer
schreibt man gerne mal keine Scripts!
Sebastian Jancke
-Sebastian
Erich Eichinger
Tx für die Rückmeldungen!
meine kürzliche Maven-Erfahrung ist einer der Gründe, warum ich nach Alternativen suche. Wer einmal die gute Luft der Konvention geschnuppert hat, will nicht mehr zum Skripten auf Händen und Knien zurück... leider brauch ich eher was OSS-mäßiges, werd' mir den FinalBuilder aber trotzdem sicher mal anschauen. Wenn Ralf und Alexander so davon begeistert sind, muss das wohl einen Grund haben ;-)
-Erich
Christian Deger
danke für das Rake Beispiel! Das könnte mir die Einstiegshürde nehmen. MSBuild vertrage ich nicht mehr :).
-Christian
Erich Eichinger
schliesse mich an - das sieht tatächlich deutlich besser aus!
From:
altn...@googlegroups.com [mailto:altn...@googlegroups.com] On Behalf Of Christian
Deger
Sent: Wednesday, August 05, 2009 1:14 PM
To: altn...@googlegroups.com
Subject: [altnetde] Re: .NET Build Systeme
Hallo Alex,
Ralf Westphal
hat, vertrag ich schon lange nicht mehr beim Thema Build.
Da hilft es auch gar nix, dass das Open Source ist. Soviel kann ich
gar nicht sparen, dass es mir die Schmerzen wert wäre.
Ich schließe mich daher Laurin an und sage: FinalBuilder ist echt die
Rettung für jeden, der mehr als 3 Tasks in irgendein Buildscript
packen muss.
Die paar Kröten, die FB kostet, hat man schon nach einem Tag Arbeit
damit vergessen.
VM ansteuern, mit VS übersetzen, über SFTP deployen, NUnit aufrufen,
Buildergebnis via MSN Messenger melden, aus Subversion auschecken,
Dateisystem manipulieren, Iteratoren für Dateien und Dateisystem, mit
Try-Catch Buildfehler abfangen und anschließend aufräumen... Das alles
und viel mehr kann man wunderbar einfach mit einer visuellen DSL in
FB. Sehr, sehr cooles Tool!
-Ralf
PS: Und wer bei mehreren Hundert "Actions" von Compilation bis
Stringmanipulation noch nicht das Passende gefunden hat, der kann mit
VBScript eingreifen oder gleich eigene Actions mit .NET schreiben.
On 6 Aug., 10:03, "Erich Eichinger" <eeichin...@gmail.com> wrote:
> schliesse mich an - das sieht tatächlich deutlich besser aus!
>
> From: altn...@googlegroups.com [mailto:altn...@googlegroups.com] On Behalf Of Christian Deger
> Sent: Wednesday, August 05, 2009 1:14 PM
> To: altn...@googlegroups.com
> Subject: [altnetde] Re: .NET Build Systeme
>
> Hallo Alex,
>
> danke für das Rake Beispiel! Das könnte mir die Einstiegshürde nehmen. MSBuild vertrage ich nicht mehr :).
>
> -Christian
>
> 2009/8/4 Alexander Groß <agr...@therightstuff.de>
>
> Hallo Erich,
>
> ich bin vor einigen Wochen auf Rake umgestiegen und mit dieser Entscheidung sehr zufrieden. Das Build Script ist im Projekt auf ungefähr ein Drittel geschrumpft und leserlicher.
>
> Ich hab das Skript bei GitHub eingestellt wenn du es dir anschauen möchtest:
>
> http://github.com/agross/rake-me/tree/master
>
> Hinweis: Das rakefile ist 1:1 aus dem Projekt übernommen.
>
Christian Raschka
anfreunden. Da sind einfach viel zu viele Dinge, die auch per
Konventionen gelöst werden könnten und mögliche Fehlerquellen gibt es
sehr viele.
Wenn ich so etwas schreiben möchte, sitze ich ja erstmal eine Woche
nur daran, das Script zu schreiben ... oder ich kopiere mir ein altes
... aber das widerspricht ja dem DRY Prinzip ...
Alexander Groß
| Da sind einfach viel zu viele Dinge, die auch per
| Konventionen gelöst werden könnten und mögliche Fehlerquellen gibt es
| sehr viele.
An welche Dinge hast du dabei konkret gedacht?
| Wenn ich so etwas schreiben möchte, sitze ich ja erstmal eine Woche
| nur daran, das Script zu schreiben ...
Aus diesem Grund darfst du gern meins oder die anderen (raken, rubicant,
rake-dotnet, etc.) als Basis verwenden. Bei FinalBuild fällt der
Einarbeitungsaufwand ebenfalls an.
| oder ich kopiere mir ein altes
| ... aber das widerspricht ja dem DRY Prinzip ...
Build Skripte beinhalten meiner Erfahrung nach immer Anteile die auf das
Projekt zugeschnitten sind. Den allgemeingültigen Rest kopiert man (aus
meiner Sicht kein DRY /innerhalb/ eines Projekts). Man beginnt einfach mit
einer etablierten Baseline. Ist es bei FinalBuilder anders?
Was ist die Alternative zum Neuschreiben oder Kopieren? Kein Build Skript?
No-Go.
Welches Buildsystem verwendest du?
Alex
--
Alexander Groß
Alexander Groß
| Da hilft es auch gar nix, dass das Open Source ist. Soviel kann ich
| gar nicht sparen, dass es mir die Schmerzen wert wäre.
du kennst bestimmt das Prinzip, dass ein Developer jedes Jahr eine neue
Sprache lernen soll. 2009 ist bei mir Ruby an der Reihe. Meine Schmerzen
halten sich also in Grenzen ;-)
Christian Raschka
Am 6. August 2009 13:01 schrieb Alexander Groß <agr...@therightstuff.de>:
> Christian,
>
> | Da sind einfach viel zu viele Dinge, die auch per
> | Konventionen gelöst werden könnten und mögliche Fehlerquellen gibt es
> | sehr viele.
>
> An welche Dinge hast du dabei konkret gedacht?
Z.B. an alle Stellen, wo Strings vorkommen. Nur wenn ich irgendwo ein
Stern oder Slash vergesse funktioniert es nicht mehr wie gewünscht.
Und warum sollte ich jedesmal wieder angeben, dass die cs
projektdateien, die Endung .csproj haben oder die NCover Ergebnisse in
einer Datei namens Coverage.xml abgelegt werden sollen? Oder die
Testdateien im Verzeichnis Test liegen? Das könnte alles per
Konvention voreingestellt (und bei Bedarf geändert) werden. Was die
Fehleranfälligkeit IMHO wesentlich erhöht.
>
> | Wenn ich so etwas schreiben möchte, sitze ich ja erstmal eine Woche
> | nur daran, das Script zu schreiben ...
>
> Aus diesem Grund darfst du gern meins oder die anderen (raken, rubicant,
> rake-dotnet, etc.) als Basis verwenden. Bei FinalBuild fällt der
> Einarbeitungsaufwand ebenfalls an.
FinalBuild habe ich noch nicht ausprobiert, deshalb kann ich dazu nichts sagen.
>
> | oder ich kopiere mir ein altes
> | ... aber das widerspricht ja dem DRY Prinzip ...
>
> Build Skripte beinhalten meiner Erfahrung nach immer Anteile die auf das
> Projekt zugeschnitten sind. Den allgemeingültigen Rest kopiert man (aus
> meiner Sicht kein DRY /innerhalb/ eines Projekts). Man beginnt einfach mit
> einer etablierten Baseline. Ist es bei FinalBuilder anders?
Warum sollte dort das DRY Prinzip nicht gelten? Was ist wenn im
Orginal ein Fehler gefunden oder eine Verbesserung eingebaut wird?
>
> Was ist die Alternative zum Neuschreiben oder Kopieren? Kein Build Skript?
> No-Go.
Die Alternative ist, dass alles was nicht projekt-spezifisch ist,
nichts in einem "Build-Skript" zu suchen hat.
>
> Welches Buildsystem verwendest du?
Da ich zur Zeit kein .NET Projekt habe, kann ich hier nur aus der Java
Welt sprechen. Dort gibt es Maven, welches sicher auch Probleme hat,
aber mir vom Ansatz her am Besten gefällt. Es wird so viel wie möglich
"Convention over Configuration" verwendet, und die Einbindung z.B. von
Coverage oder Style Tools nur in der Einbindung von Plug-Ins besteht:
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>maven-clover2-plugin</artifactId>
<version>${clover.version}</version>
</plugin>
Es gibt ein Projekt, welches Maven verwendet um .NET Projekte zu
bauen: NPanday (http://npanday.codeplex.com/). Ist noch relativ jung,
mal schauen, wie es sich entwickelt.
>
> Alex
>
> --
> Alexander Groß
>
Christian Raschka
Alexander Groß
| Z.B. an alle Stellen, wo Strings vorkommen. Nur wenn ich irgendwo ein
| Stern oder Slash vergesse funktioniert es nicht mehr wie gewünscht.
das ist bei allen Skriptsprachen so und auch bei kompiliertem Code. Und
wahrscheinlich auch bei Maven, wenn man dort angibt wo vom Plugin zu
bearbeitenden die Projekte/Dateien liegen.
| Das könnte alles per
| Konvention voreingestellt (und bei Bedarf geändert) werden. Was die
| Fehleranfälligkeit IMHO wesentlich erhöht.
Die Fehleranfälligkeit wird erhöht? ;-)
Die Konventionen bzw. Defaults finden sich in der properties.yml-Datei. Dort
kann man sicher auch noch einiges einbauen, z. B. welche Endung die
Projektdateien haben.
| > | Wenn ich so etwas schreiben möchte, sitze ich ja erstmal eine Woche
| > | nur daran, das Script zu schreiben ...
Nach wie vor gilt aus meiner Sicht, dass es auch bei Maven seine Zeit dauert
bevor das Build Skript/die Pluginkonfiguration steht. Da wird man selbst mit
visuellen Tools nicht umhin kommen.
| > | oder ich kopiere mir ein altes
| > | ... aber das widerspricht ja dem DRY Prinzip ...
| >
| > Build Skripte beinhalten meiner Erfahrung nach immer Anteile die auf das
| > Projekt zugeschnitten sind. Den allgemeingültigen Rest kopiert man (aus
| > meiner Sicht kein DRY /innerhalb/ eines Projekts). Man beginnt einfach
mit
| > einer etablierten Baseline. Ist es bei FinalBuilder anders?
|
| Warum sollte dort das DRY Prinzip nicht gelten? Was ist wenn im
| Orginal ein Fehler gefunden oder eine Verbesserung eingebaut wird?
Im oben verlinkten Rake-Skript findet sich der Ordner tools/Rake, wo die
Basisfunktionalität liegt. Die kannst du per svn:externals oder Git
Submodules einbinden und somit wiederverwenden. Was und wie gebaut wird,
gehört IMHO dennoch in jedes Projekt weil spezifisch.
| Es wird so viel wie möglich
| "Convention over Configuration" verwendet, und die Einbindung z.B. von
| Coverage oder Style Tools nur in der Einbindung von Plug-Ins besteht:
|
| <plugin>
| <groupId>com.atlassian.maven.plugins</groupId>
| <artifactId>maven-clover2-plugin</artifactId>
| <version>${clover.version}</version>
| </plugin>
Mein erster Gedanke dazu: Ugh, XML. Wie groß werden solche Skripte? Bindet
man letztenendes nur noch eine Reihe von Plugins ein (= das
Projektspezifische am Build Skript)?
Wie gesagt, Convention over Configuration kannst du auch in Rake oder einem
anderen Build Tool nachbauen.
Sebastian Jancke
> das ist bei allen Skriptsprachen so und auch bei kompiliertem Code. Und
> wahrscheinlich auch bei Maven, wenn man dort angibt wo vom Plugin zu
> bearbeitenden die Projekte/Dateien liegen.
src/main/java (oder csharp oder scala, ...)
und Resourcen in
src/main/resources
Alle Tests liegen entsprechend in src/test/... you get it.
Die meisten Plugins muss man nicht konfigurieren, denn über die
Defaults funktionieren die einfach out-of-the-box.
Wer keine Maven-POMs tippen mag, ist in der Regel ganz gut mit dem
verfügbaren IDE-Tooling aufgehoben (Editoren für alles, Suche nach
Dependencies im zentralen Maven-Repository, ...).
>Wie groß werden solche Skripte?
ist größe weniger ein Problem als bei komplizierten Statements.
>Wie gesagt, Convention over Configuration kannst du auch in Rake oder einem
>anderen Build Tool nachbauen.
>Nach wie vor gilt aus meiner Sicht, dass es auch bei Maven seine Zeit dauert
>bevor das Build Skript/die Pluginkonfiguration steht. Da wird man selbst mit
>visuellen Tools nicht umhin kommen.
verlieren. Man sagt welche Dependencies man hat, wenn man einen
speziellen Compiler hat, bennent man den auch, sagt welche Plugins man
will (Coverage, ...) und das wars. Aus Erfahrung kann ichs agen das
bestimmt 80% nichts zu tun ist außer dem bloßen Statement "ich will
plugin/dependency XY". Dies macht es wirklich Einfach.
Ein weiteres Plus: Alle Projekte sehen weltweit gleich aus. Man findet
sich sofort zurecht und muss nicht suchen. Im Vergleich zu Eclipse und
anderen großen Quellen wirklich ein Segen. Wer dort schonmal suchen
musste, weiß wovon ich heule...
Grüße
Sebastian
Steve Wagner
Video von Jeffrey Snover gesehen wo er ein auf Powershell basiertes make
geschrieben hat um die Fähigkeiten der Powershell zu zeigen. Er hat das
ganze aber nie veröffentlich. Da ich zu der Zeit mit grad mit Powershell
auseinander gesetzt hatte, hab ich das ganze einfach nachprogrammiert
aber es aus Zeitgründen noch nicht veröffentlicht.
Eine beispielhaftes makefile.ps1 sieht dann so aus:
-------------------------------------
target all clean hallo.exe cshallo.exe
target test all {
"start hallo.exe"
./hallo.exe
"start cshallo.exe"
./cshallo.exe
}
target clean {
write-host "cleaning files"
remove-item hallo.exe
remove-item cshallo.exe
}
# build hallo.exe
target hallo.exe main.obj,do_hallo.obj,{write-host "inline script"}
target main.obj main.c
target do_hallo.obj do_hallo.c,message.h
# build cshallo.exe
target cshallo ((dir "test*cs")+"mylib.dll")
# build mylib.dll
target mylib.dll mylib.cs
----------------------------------------
Aufgerufen wird es dann so:
./poshmake all
Das ganze funktioniert folgendermaßen: Target ist eine Funktion die als
ersten Parameter den Namen des neuen Targets bekommt. Danach kommen
alles was dieses Target voraussetzt. Die Besonderheit ist das dies nicht
nur andere Targets, sondern auch Dateien, inline Scripte oder Powershell
Befehle sein können. Damit das ganze jetzt noch funktioniert gibt es für
bestimmte Dateien vordefinierte Build actions. z.B. kommen ein oder
mehrere cs Dateien werden diese an CSC übergeben und mit dem namen das
targets kompiliert. Brauch man spezielle CSC Parameter kann man einfach
ein inline Script vor den Task legen welches diese der variable
$CSCFLAGS hinzufügt.
z.B. das Target "test" basiert auf "all" womit erst all komplett gebaut
wird, danach kommt ein mehrzeiliges inline Script welches die passenden
Aktionen ausführt.
Befehle wie copy, move und delete können alle direkt über die Powershell
abgebildet werden und die die noch fehlen werden auch direkt über die
Powershell nachgerüstet.
Die Buildscripte sind wie rake wesentlich kürzer als in nant oder
msbuild, allerdings hat man volle .Net Unterstützung und die Powershell
ist im Gegensatz zu Ruby direkt dafür ausgelegt auf der Commandozeile
gut zu funktionieren und bringt schon sehr viele nützliche Befehle mit.
Außerdem muss man keine neue Klassenbibliothek lernen.
Das ganze ist momentan noch als eher experimentell und nicht für den
Projekteinsatz reif. Da mir aber meist die Zeit fehlt, bräuchte ich
Hilfe um das zu nem Release bringen zu können.
Steve
Alexander Groß schrieb:
>
>
>
> ich bin vor einigen Wochen auf Rake umgestiegen und mit dieser Entscheidung sehr zufrieden. Das Build Script ist im Projekt auf ungefähr ein Drittel geschrumpft und leserlicher.
>
>
>
> Ich hab das Skript bei GitHub eingestellt wenn du es dir anschauen möchtest:
>
> http://github.com/agross/rake-me/tree/master
>
>
>
> Hinweis: Das rakefile ist 1:1 aus dem Projekt übernommen.
>
>
>
Laurin Stoll
hm... man könnte gerade das Gefühl kriegen ich möchtet scripten ;-)
@alexander: ich bin nicht ganz einig mit dir. Ich hatte nicht wirklich
einen einarbeitungsaufwand.... vorallem lassen sich solche listen mit
variablen versehen, einfach kopieren und nach änderung der variable
passt alles auf ein neues projekt. ich habe von der ersten sekunde
nichts gelesen oder ähnliches..... ich würde euch also wirklich dazu
raten, die paar € hin oder her....
>
> - Zitierten Text anzeigen -
Alexander Groß
Alex
--
Alexander Groß
http://therightstuff.de/
| -----Original Message-----
| From: altn...@googlegroups.com [mailto:altn...@googlegroups.com] On
| Behalf Of Steve Wagner
| Sent: Thursday, August 06, 2009 5:38 PM
| To: altn...@googlegroups.com
| Subject: [altnetde] Re: .NET Build Systeme
|
|
Steve Wagner
Alexander Groß schrieb:
Sebastian Jancke
Bei Make-Derivaten wie MSBuild ist mein Problem vor allem, das immer noch Convention-over-Configuration fehlt und allen Ansätzen außer Maven fehlt ein Dependency und Release-Management. Für Ant (Java) gibt es dafür Ivy, leider ist die Portierung von Codehaus zu Ivy.Net weder öffentlich noch irgendwie fertig...
Ich werde versuchen bis zum #netos09 mal NPanday zu untersuchen, vielleicht kriegen wir ja eine detailierte Diskussion zum Thema hin.
-Sebastian
Erich Eichinger
danke für die Klärung - ich denke, du hast den Nagel auf den Kopf getroffen. Es ist der imperative Ansatz von NAnt, MSTest & Co, der mich so nervt. Und seit meinem Maven-Erstkontakt wünsche ich mir ein Tool auf der dunklen Seite, dass dieselben starken Konventionen bietet und erlaubt, einfach nur deklarativ die Abhängigkeiten anzugeben bzw. Ouput-Features zu "aktivieren" (z.B. NCover, NUnit etc.) - fertig. Ich bin bereit, mich jeder Konvention zu unterwerfen, wenn ich dafür keine build-Skripte debuggen muß.
Maven ist hier meiner Meinung nach sogar ein sehr gutes Beispiel für eine "starke" Konvention: Es erlaubt, die "guten" Dinge einfach zu machen, lässt die "schlechten" Dinge (workarounds, hacks whatever) aber durchaus zu - nur muß man halt was dafür tun. Um die "guten" Tasks zu meistern hab ich genau 3h Einarbeitungszeit in ein großes Projekt ohne jegliche Maven-Vorkenntnisse gebraucht. Um eine Lösung für einen Spezialfall einzubauen 1 Tag. Meistens beschränkt sich das sowieso lediglich auf einen Plugin-Download und dessen Einbindung.
-Erich
From:
altn...@googlegroups.com [mailto:altn...@googlegroups.com] On Behalf Of Sebastian
Jancke
Sent: Thursday, August 06, 2009 8:04 PM
To: altn...@googlegroups.com
Subject: [altnetde] Re: .NET Build Systeme
Ich habe noch ein wenig über
die Diskussion nachgedacht. Es erscheint mir mehr und mehr, dass mir die
"DSL" eigentlich ziemlich egal ist. Ich sehe aber einen gravierenden
Unterschied zwischen prozeduralem Ant/Rake/..., teilweise deklarativen
Make-Derivaten und deklarativen Ansätzen wie Maven.
Alexander Groß
Zum Thema Dependency Management haben die ALT.NETter aus Schottland das Projekt Horn gerade in Entwicklung. Ich hab es mir nur mal kurz überflogen, falls es für jemanden von euch von Interesse ist.
+1 für eine Session auf dem Open Space.
From:
altn...@googlegroups.com [mailto:altn...@googlegroups.com] On Behalf Of Sebastian
Jancke
Sent: Thursday, August 06, 2009 8:04 PM
To: altn...@googlegroups.com
Subject: [altnetde] Re: .NET Build Systeme
Ich habe noch ein wenig über
die Diskussion nachgedacht. Es erscheint mir mehr und mehr, dass mir die
"DSL" eigentlich ziemlich egal ist. Ich sehe aber einen gravierenden
Unterschied zwischen prozeduralem Ant/Rake/..., teilweise deklarativen
Make-Derivaten und deklarativen Ansätzen wie Maven.
--~--~---------~--~----~------------~-------~--~----~
Sie erhalten diese Nachricht, weil Sie Mitglied sind von Google Groups-Gruppe
"altnetde".
Sebastian Jancke
Horn ist interessant, zielt aber vor allem auf integration von Quellen.
Dies halte ich in sofern für schwierig, da ich eigentlich lieber gegen
ein festes Set von Release-Versionen arbeiten möchte
(Reproduzierbarkeit!) die am besten auch noch offiziell signiert in
einem öffentlichen Repository liegen. Davon ab trotzdem ein
interessantes Projekt.
Btw: Wir haben NPanday kompilieren können und damit ein erstes
Sample-Projekt bauen können. Die VS-Integration konnte ich noch nicht
ausprobieren.
-Sebastian
Alexander Groß schrieb:
> von Interesse ist.
>
>
>
> +1 für eine Session auf dem Open Space.
>
>
>
> Alex
>
>
>
> --
>
> Alexander Groß
>
> http://therightstuff.de/
>
>
>
> Behalf Of *Sebastian Jancke
> *Sent:* Thursday, August 06, 2009 8:04 PM
> *To:* altn...@googlegroups.com
> *Subject:* [altnetde] Re: .NET Build Systeme