Seite 2: Optionen

Inhaltsverzeichnis

MSBuild-Optionen

Die Groß- und Kleinschreibung spielt bei den Optionen keine Rolle. Die Verbosity (Gesprächigkeit) /verbosity oder /v gibt an, wie viel Informationen MSBuild ausgibt. Die Levels reichen von [q]uiet über [m]inimal, [n]ormal, [d]etailed bis hin zu [diag]nostic. In eckigen Klammern stehen die mit MSBuild ebenfalls verwendbaren Abkürzungen. Leider ist die Abstufung zwischen minimal und normal nicht gut gelungen. Während "minimal" nicht einmal die Nachrichten eines normalen Message-Tags und auch keine Erfolgsmeldung ausgibt, gibt "normal" neben Message-Tags und der Erfolgsmeldung noch Informationen über Beginn und Ende eines Targets sowie weitere Metainformationen an, welche die Ausgabe etwas unübersichtlich gestalten.

In Verbindung mit Silverlight eignet sich MSBuild dafür, ohne manuelle Eingriffe die Artefakte (Ergebnisse des Build-Vorgangs) herstellen, sowie die Paketierung (Auswahl der Dateien und Setup-Erstellung) und das Deployments durchzuführen zu können.

Folgende Build-Umgebung wird automatisch erzeugt, ohne dass der Entwickler viel dazu tun muss. Legt man ein Projekt des Typs "Silverlight Application" mit Visual Studio an, importiert die Projektdatei die Silverlight-Targets:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\Silverlight\
        $(SilverlightVersion)\Microsoft.Silverlight.CSharp.targets" />

Mehr Infos

Auch CruiseControl.NET ist auf den Einsatz von MSBuild vorbereitet, und die Logs und die Erfolgsmeldungen lassen sich ohne weiteren Aufwand lesen. Die Datei ThoughtWorks.CruiseControl.MSBuild.dll, die für das Logging aus CruiseControl erforderlich ist, wird standardmäßig mitgeliefert. Es gibt die Option, den Rodemeyer-Logger (Rodemeyer.MsBuildToCCnet.dll) einzubinden, der das Dashboard besser strukturiert. Die Installation des Build-Servers und die Fehlersuche gestalten sich aber aufwendiger.

Die Targets für Silverlight liegen standardmäßig im Verzeichnis %Program Files%\MSBuild\Microsoft\Silverlight\. Die Target-Dateien für C# und Visual Basic .NET enthalten die Import-Anweisung für die Microsoft.Silverlight.Common.targets. Hier geschieht die eigentliche Arbeit. Die Tasks CompileXaml, ValidateXaml und XapPackage sprechen für sich. Die .NET-DLL Microsoft.Silverlight.Build.Tasks.dll referenziert die XamlServices.dll, die die als Open Source vorliegende C-Komponente zlib114.dll benutzt. Alle liegen im selben Verzeichnis und können Teil der Paketierung sein.

Um eine Automatisierung zu erreichen, lässt sich im einfachsten Fall MSBuild im Verzeichnis der Projektdatei aufrufen. Alle Artefakte werden nun erzeugt. Mit Kenntnis der Zusammenhänge kann man zudem manuelle Konfigurationen einfügen, welche die Silverlight-Tasks aufrufen.

Die Erstellung eines Tasks in Eigenregie gestaltet sich einfach. Man kann das ITask-Interface implementieren, dazu muss man neben bool Execute() auch die Get- und Set-Properties BuildEngine und HostObject implementieren. Leitet man von der Basisklasse Task ab, lässt sich das sparen.

using System;
using Microsoft.Build.Utilities;
using Microsoft.Build.Framework;

namespace YourTasks
{
    public class HelloWorld : Task
    {
        public override bool Execute()
        {
            Log.LogMessage("HelloWorld");
            return true;
        }
    }
}

Zu beachten ist, dass die Ausgabe auch mit Console.WriteLine erfolgen kann.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="A">
    <Csc Sources="helloworldtask.cs" OutputAssembly=
         "YourTasks.HelloWorld.dll" TargetType="library" 
              References="Microsoft.Build.Utilities.dll;
                  Microsoft.Build.Framework.dll"/>
</Target>
</Project>

Ruft der Entwickler die Datei mit msbuild helloworldtaskcompile.msbuild auf, entsteht eine YourTasks.HelloWorld.dll im aktuellen Verzeichnis. Für das Beispiel kann sie hier liegen bleiben. Nun erfolgt die Einbindung des geschriebenen Tasks mit dem MSBuild-Skript.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="HelloWorld" 
           AssemblyFile="YourTasks.HelloWorld.dll" />
<Target Name="A">
  <HelloWorld/>
</Target>
</Project>

Der Aufruf gibt schließlich das Ergebnis aus.

Der fertige Task ist entweder – wie hier – per UsingTask-Tag zu referenzieren oder in das .NET-Framework-Verzeichnis, standardmäßig C:\WINDOWS\Microsoft.NET\Framework\v3.5, zu kopieren. Häufig wird behauptet, das Implementieren von eigenen Tasks sei einfach. Das ist nicht zutreffend, wenn man einen Task mit Eingabe und Ausgabe programmiert und auch ein ordentliches Exception-Handling und Logging bekommen möchte. Das ist nur bei einfachen Tasks trivial, es erfordert eine detaillierte Auseinandersetzung mit dem Erweiterungskonzept. Dieser Aufwand ist bei einem eigenständigen Tool nicht erforderlich. Das Schreiben eines Custom Task sollte man daher in der Projektplanung nicht in dieselbe Schublade wie das Programmieren von ein paar Zeilen Skript stecken.