Im zwölften – und letzten – Teil der Artikelserie “Das MSBuild Universum” möchte ich IronMSBuild vorstellen. Zunächst aber nochmals eine kurze Liste aller Beiträge der Artikelserie
- MSBuild – Ein Überblick
- MSBuild – Leichte Kost
- MSBuild – Jenseits von HelloBuildWorld (MSBuild Properties)
- MSBuild Items – Die Planeten im Universum
- MSBuild Tasks - Die Umlaufbahnen im Universum
- MSBuild Conditions – Die Wurmlöcher des Universums
- MSBuild Custom Tasks – Sternschnuppen im MSBuild Universum
- MSBuild Targets – Die Asteroiden im MSBuild Universum nutzen
- MSBuild Logger - Reisen im Universum sollte man protokollieren
- MSBuild Batching und MSBuild Choose – Die Flugbahnen von Körpern im Universum beeinflussen
- MSBuild Hook Ups - Die Tore zum Ur-Universum
Mit IronMSBuild ist es möglich dynamischen Code (momentan IronRuby und IronPython) in ein Buildscript zu integrieren. Die gewonnenen Möglichkeiten hierdurch sind enorm. Alles was mit .NET mitteln entwickelt werden kann, kann jetzt auch in Buildscripten integriert werden, ohne für sämtliche Aktionen eigene Tasks entwickeln zu müssen.
Wie funktioniert IronMSBuild
IronMSBuild bildet momentan die Ausführung von dynamischem Code in Form von Tasks ab. Für die Ausführung des dynamischen Codes ist die DLR (Dynamic Language Runtime) verfügbar, welche im IronTask gehostet wird. Am leichtesten lässt sich die Funktionsweise von IronMSBuild anhand eines kleinen Schaubilds darstellen
Das Schaubild stellt die einzelnen Bestandteile dar, die bei der Ausführung eines IronTask’s zusammenspielen. Da die drei Hauptbestandteile, das MSBuild Script, der MSBuild Prozess und die CLR sollten soweit eigentlich bekannt sein sollten, gehe ich hier nur näher auf die Details ein.
IronTask
Der IronTask ist im Schaubild zweimal vorhanden, einmal deklarativ im MSBuild Script und einmal in Form einer IronTask Instanz innerhalb des MSBuild-Prozesses.
Im der deklarativen Version kann ein Script (IronRuby oder IronPython) hinterlegt werden.
In der IronTask Instanz wird entsprechend der Einstellung eine ScriptRuntime der DLR gehosted. Somit ist jeder Task unabhängig von Drittkomponenten. Die jeweilige ScriptRuntime ist für die Ausführung der Skripte verantwortlich
Die hosted DLR
Die gehostete DLR (Dynamic Language Runtime) ist wie bereits erwähnt für die Ausführung der Scripte verantwortlich. Um den Scriptentwicklern mehr Flexibilität zu geben, habe ich den verwendbaren ScriptScope um einige Variablen erweitert, die innerhalb eines Tasks interessant und hilfreich sein könnten.
- currentTask
- Die aktuelle Task Instanz
- hostObject
- Das HostObjekt des aktuellen Tasks
- log
- Der mit dem Task verfügbare Logger
- buildEngine
- Die mit dem aktuell verwendeten Task assoziierte BuildEngine
In Verbindung mit diesen Properties hat man die Möglichkeit schnell effektive Scripte für den Buildvorgang zu entwickeln.
Der Build-Ablauf
In Abbildung 1 habe ich fünf Punkte eingefügt, die ich etwas näher erläutern möchte
- Ausgehend von MSBuild.exe wird das BuildScript geladen
- Im Buildscript ist ein IronTask deklariert, daher wird im managed MSBuild Prozess eine neue Instanz von IronTask angelegt
- Das eigentliche Script (Property IronRubyScript oder IronPythonScript) wird in die Taskinstanz geladen
- Bei der eigentlichen Ausführung des Tasks (Methode Execute) werden folgende Schritte durchgeführt
- DLR hosting (ScriptRuntime, ScriptScope, ScriptEngine)
- Variablen in DLR SrciptScope übergeben (currentTask,hostObject,..)
- Das eigentliche Script wird über die DLR in CLR Code umgewandelt und ausgeführt
- Eventuelle Rückgabewerte werden wieder zurück an den IronTask gegeben und über die Property Result verfügbar gemacht
Ein einfaches Beispiel
Ein kleines Beispiel der Deklaration wird sicher die letzten Unklarheiten beseitigen, was die Verwendung von IronMSBuild angeht.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
ToolsVersion="3.5"
DefaultTargets="IronBuild">
<PropertyGroup>
<RubyScript>
<![CDATA[
File.open("IronMSBuild.txt", "w") do |file|
15.times do |i|
file.write "IronMSBuild! This is going to rock build processes!\n"
file.write "http://www.dotnet-rocks.de "*i
file.write "\n\n"
end
end
]]>
</RubyScript>
</PropertyGroup>
<UsingTask AssemblyName="IronMSBuild"
TaskName="IronMSBuild.Tasks.IronTask">
</UsingTask>
<Target Name="IronBuild">
<IronTask IronRubyScript="$(RubyScript)"/>
</Target>
</Project>
Führt man das BuildScript aus, wird der folgende Inhalt (wg. der Übersicht abgeschnitten..) in die Datei IronMSBuild.txt geschrieben
IronMSBuild! This is going to rock build processes!
IronMSBuild! This is going to rock build processes!
http://www.dotnet-rocks.de
IronMSBuild! This is going to rock build processes!
http://www.dotnet-rocks.dehttp://www.dotnet-rocks.de
IronMSBuild! This is going to rock build processes!
http://www.dotnet-rocks.dehttp://www.dotnet-rocks.dehttp://www.dotnet-rocks.de
IronMSBuild! This is going to rock build processes!
http://www.dotnet-rocks.dehttp://www.dotnet-rocks.dehttp://www.dotnet-rocks.dehttp://www.dotnet-rocks.de
…
…
…
Fazit zu IronMSBuild
IronMSBuild wird in den nächsten Tagen auf CodePlex veröffentlicht und kann somit frei von jedem verwendet werden. Ich hoffe dass sich viele Anhänger dieses Ansatzes finden, die sowohl Spaß an dynamischen Sprachen und MSBuild haben!
Fazit zu “Das MSBuild Universum”
Mit dem Artikel über IronMSBuild geht die Artikelserie “Das MSBuild Universum” zwar zu Ende, allerdings werden in der nächsten Zeit noch viele Posts rund um MSBuild oder Build-Allgemein folgen. Die Artikelserie über MSBuild hat wirklich Spaß gemacht und ich hoffe, dass ich vielen Interessenten und .NET Entwicklern weiter geholfen hat.
Sollten noch Fragen bezüglich MSBuild offen sein, nur her damit :)
Also weiterhin schön Build-Scripts schreiben und ab und an hier vorbeischauen, um zu sehen was es neues rund um MSBuild gibt.