Bob, der Software-Baumeister

Transkript

1 Automatisches Erstellen von Installationsprogrammen mit MSBuild & Co. Bob, der Software-Baumeister Builds im Softwareentwicklungsprozess zu automatisieren ist heute nahezu der Normalfall. Und was ist mit dem dazugehörigen Setup-Programm? Mit geringem zusätzlichem Aufwand lässt es sich dank der Microsoft Build Engine und einiger weiterer Tools ebenfalls automatisch erzeugen. Auf einen Blick Andreas Kerl ist freiberuflicher Softwareentwickler, IT- Trainer und Fachautor. Er ist Spezialist für die Windows- Installer-Technologie und hat mehrere Bücher hierzu veröffentlicht. Sie erreichen ihn unter Inhalt Das automatische Erzeugen von Setup-Programmen lässt sich auf einem Build-Server gleich mit erledigen. Als Alternative kommt in erster Linie Windows Installer XML infrage. Für das Erzeugen von Updates ist unter Umständen das Tool Paraffin besser geeignet. Erfordert ein Build weitere Aktionen danach, empfiehlt sich das Tool FinalBuilder. dnpcode A1009Setup Vor einem Build-Prozess sind dievoraussetzungen zum Erstellen eines Setups zu schaffen, wobei die Auswahl der richtigen Technologie eine wesentliche Rolle spielt. Der Gedanke liegt nahe, die Setup- und Bereitstellungsprojekte von Visual Studio dafür in Betracht zu ziehen sie sind Teil der Entwicklungsumgebung und scheinen für einfache Anwendungsinstallationen ausreichend. Leider führt das aber nicht zum Ziel, denn die von Visual Studio erzeugte VDPROJ-Projektdatei ist nicht kompatibel mit MSBuild, sodass in diesem Fall immer die Entwicklungsumgebung von Visual Studio (devenv.exe) erforderlich ist. Diese ist auf dem Rechner eines Entwicklers zwar vorhanden, aber nicht unbedingt auf einem Build-Server, der seine Prozesse automatisch abwickeln soll abgesehen davon, dass eine IDE hier auch nicht erwünscht ist; eine andere Technologie ist gefragt. Der Markt für solche Technologien ist groß und wächst ständig. Das macht es nicht immer einfach, das geeignete Werkzeug zu finden. In der Vergangenheit hat sich allerdings die Tool-Sammlung Windows Installer XML (WiX) [1] etabliert und empfiehlt sich somit als erste Wahl für diesen Zweck. Das XML-Format ist Entwicklern vertraut, und sie können die in XML beschriebenen Bestandteile und Inhalte der Installation sehr einfach nachvollziehen. Das Installationspaket aufbauen Im ersten Schritt geht es darum, das Installationspaket zu konstruieren. Da es sich bei Windows Installer XML um keine Prozedursprache, sondern um eine Deklarationssprache handelt, beschreibt es nicht die einzelnen Installationstätigkeiten. Vielmehr ist in dem XML-Dokument mit der Endung WXS, das den Build-Prozess steuert, das gewünschte Ergebnis der Installation zu definieren. XML-Dokumente lassen sich mit nahezu jedem Editor erzeugen und bearbeiten, so also auch Windows Installer XML. Wesentlich bequemer ist es allerdings, die Tool-Sammlung in Visual Studio einzubinden [2], da der Komfort durch IntelliSense und das Hervorheben des Quellcodes die Arbeit viel einfacher macht. Entscheidend ist, dass die von Visual Studio erzeugte WIXPROJ-Projektdatei und die SLN-Projektmappen-Datei kompatibel mit MSBuild sind; automatisierte Builds sind somit sehr einfach zu verwirklichen, ohne dass Visual Studio auf dem System vorhanden sein muss. Darüber hinaus lässt sich dieselbe Umgebung zum Entwickeln der Anwendungen und des Installationsprogramms verwenden, sodass eine neue Einarbeitungszeit nicht erforderlich ist. Listing 1 zeigt ein WiX-Beispielprojekt, das ein Windows-Installer-basiertes Setup für eine kleine Anwendung erzeugt. Das Element <Product> enthält Metainformationen, die das Produkt innerhalb des Windows-Installer-Repositorys kennzeichnen und identifizieren. Diesem Element sind mehrere Elemente untergeordnet; dabei nimmt <Directory> eine exponierte Stellung ein. Dass es sich bei Windows Installer XML um eine Deklarationssprache handelt, lässt sich hervorragend an der Ordnerstruktur begutachten, die Listing 1 definiert. Dazu gehört ein Order mit der ID INSTALLLOCATION: <Directory Id="INSTALLLOCATION" Name="$(var.ProductName)" FileSource="$(var.SourceFolder)"> Das Verzeichnis liegt unterhalb des Ordners ProgramFilesFolder. Daraus folgt, dass bei der späteren Installation die Referenz gegen den absoluten Pfad des Programmverzeichnisses aufgelöst wird und hierunter das Zielverzeichnis erstellt wird. Der Name des Zielverzeichnisses ist mit $(var.productname) bezeichnet. Es handelt sich hierbei um eine Präprozessorvariable, die das Element <?define?> zu Beginn des Dokuments festlegt. In diesem Ordner wird die ausführbare Datei ImageViewer.exe gespeichert: <File Id="F ImageViewer.pdb" Name="ImageViewer.pdb" KeyPath="yes" DiskId="1" /> Zusätzlich wird hier auch die PDB-Symboldatei abgelegt, allerdings nur, wenn die Debug- Version des Produkts erzeugt werden soll. Die Präprozessorvariable Configuration wird von Visual Studio je nach Einstellung auf die Werte Debug oder Release gesetzt. Die WXS-Datei kann auf den Inhalt dieser Variablen zugreifen und das In

2 Listing 1 Das WXS-Dokument zu einem Installationspaket. <?xml version="1.0" encoding="utf-8"?> <!--Deklaration der Variablen--> <?define ProductVersion =" "?> <?define ProductName ="Image Viewer"?> <?define SourceFolder ="D:\dotnetpro\Demo\Bin"?> <?if $(var.configuration) = "Debug"?> <?define ProductCode ="{DA C-0D52A9BA2F81}"?> <?else?> <?define ProductCode ="{7493A8F8-CFBD-4e D1898D5B441}"?> <?endif?> <Wix xmlns=" <!-- Definition des Produktes --> <Product UpgradeCode="{A080E20D-BBCC-472d-99EA EF}" Manufacturer="Andreas Kerl" Language="1033" Version="$(var.ProductVersion)" Name="$(var.ProductName)" Id="$(var.ProductCode)" Codepage="1252"> <!-- Paketdefinition --> <Package Manufacturer="Andreas Kerl" InstallerVersion="500" Platform="x86" Languages="1033" Compressed="yes" SummaryCodepage="1252" InstallPrivileges="elevated" /> <!-- Systemvoraussetzung --> <PropertyRef Id="NETFRAMEWORK35" /> <Condition Message="Das Microsoft.NET Framework 3.5 ist zur Ausführung der Applikation unbedingt erforderlich.">netframework35</condition> <!--Ordnerstruktur--> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFilesFolder"> <Directory Id="INSTALLLOCATION" Name="$(var.ProductName)" FileSource="$(var.SourceFolder)"> <!--Anwendung--> <Component Id="C ImageViewer.exe" Guid="{CBCCCA47-DB89-46ce-82C4-11F9DA73DE65}"> <File Id="F ImageViewer.exe" Name="ImageViewer.exe" KeyPath="yes" DiskId="1"/> </Component> <!--Symboldatei in Abhängigkeit zur Konfiguration integrieren--> <?if $(var.configuration) = "Debug"?> <Component Id="C ImageViewer.pdb" Guid="{ E-B489-4f0b B6FEA56245}"> <File Id="F ImageViewer.pdb" Name="ImageViewer.pdb" KeyPath="yes" DiskId="1" /> </Component> <?endif?> </Directory> <Directory Id="MyPicturesFolder"/> </Directory> </Directory> <!-- Definition der Featurestruktur --> <Feature Id="Application" Title="Anwendung" Level="1"> <ComponentRef Id="C ImageViewer.exe" /> <?if $(var.configuration) = "Debug"?> <ComponentRef Id="C ImageViewer.pdb" /> <?endif?> <!--Verweis auf weitere Komponenten--> <ComponentGroupRef Id="CG Images"/> </Feature> // Fortsetzung auf der nächsten Seite

3 _ Automatisches Erstellen von Installationsprogrammen mit MSBuild & Co. Listing 1 Das WXS-Dokument zu einem Installationspaket (Fortsetzung). <!-- Medien --> <Media Id="1" EmbedCab="yes" Cabinet="Data.cab" /> <!-- Zertifikate integrieren --> <PatchCertificates> <DigitalCertificate Id ="GenericCertificate" SourceFile ="$(var.certificatefile)"/> </PatchCertificates> <PackageCertificates> <DigitalCertificate Id ="GenericCertificate" SourceFile ="$(var.certificatefile)"/> </PackageCertificates> <!-- UI-Definition --> <Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION" /> <UIRef Id="WixUI_InstallDir" /> </Product> </Wix> stallationslayout entsprechend anpassen, wie das folgende Codefragment zeigt: <?if $(var.configuration) = "Debug"?> <! Do Something--> <?endif?> Dieser Anpassungsmöglichkeit bedient sich das WXS-Dokument auch zu Beginn: <?define ProductCode ="{DA C-0D52A9BA2F81}"?> Bei ProductCode handelt es sich um die Kennzeichnung, die ein Windows-Installer-Produkt eindeutig identifiziert. Es erscheint angebracht, hierbei ebenfalls zwischen Debug- und Release-Version des Produkts zu differenzieren, die durch unterschiedliche GUIDs gekennzeichnet sind. Im Deklarationsbereich des Dokuments finden sich auch die Definitionen für die Produktversion, für den Produktnamen und für das Verzeichnis der Quelldateien. Diese Abstraktionen machen das Dokument übersichtlicher und erlauben es, es flexibler zu halten, da Änderungen nur an einer Stelle vorzunehmen sind. Das Installationspaket lässt sich nun durch die Build-Befehle aus Visual Studio problemlos erzeugen. Einen Build parametrisieren Ein Problem des bisher konstruierten Dokuments ergibt sich daraus, dass alle Einstellungen statisch sind. Das bedeutet, dass bei einer Änderung desverzeichnisses für die Quelldateien das WXS-Dokument modifiziert werden muss. Gleiches gilt für eine Änderung des Produktnamens und der Produktversion. In allen Fällen sind die entsprechenden Wertzuweisungen im Deklarationsbereich anzupassen. Um eine größere Flexibilität in automatisierten Prozessen zu erreichen, sollte es aber möglich sein, die entsprechenden Variablen beim Start des Builds festzulegen, ohne das WXS-Dokument selbst ändern zu müssen. Auf den ersten Blick scheint dies recht einfach umsetzbar, denn in den Projekteigenschaften lassen sich ebenfalls die Präprozessorvariablen festlegen. Bei genauerer Betrachtung bringt diese Lösung aber keine Verbesserung, denn die Wertefestlegung findet nun in der WIXPROJ-Projektdatei statt. Ist jetzt das Verzeichnis der Quelldateien oder eine andere Eigenschaft zu ändern, muss also diese Projektdatei modifiziert werden damit aber ist nichts gewonnen. Beim Aufruf von msbuild.exe ist es möglich, Werte auf Projektebene zuzuweisen, sodass der nachfolgende Aufruf geeignet scheint, das Problem zu lösen: msbuild.exe setup.wixproj /p:sourcefolder=d: \Demo\Bin Beim Testen macht sich allerdings schnell Ernüchterung breit, denn der Build schlägt mit der folgenden Meldung fehl: CNDL0150: Undefined preprocessor variable '$(var.sourcefolder)'. Hieraus lässt sich ableiten, dass MSBuild nicht auf die von WiX verwendeten Präprozessorvariablen zugreifen kann. Abhilfe schaffen hier nur Präprozessorvariablen, die expliziert für die Build Engine definiert werden; dazu ist die Syntax $(Property- Name) zu verwenden. Für das gerade skizzierte Beispiel ist es also erforderlich, die Definition der Präprozessorvariablen Source- Folder in den Eigenschaften des Projekts von SourceFolder=D:\Demo\Bin zu verändern, beispielsweise zu SourceFolder= $(Folder), wie es Abbildung 1 zeigt. Dies erzeugt für MSBuild die Präprozessorvariable Folder, die nun über die Befehlszeile zur Verfügung steht. Erfolgt hier einewertzuweisung, überträgt MSBuild die Informationen an die Präprozessorvariable SourceFolder von Windows Installer XML. Das Gleiche gilt für die Festlegung des Produktnamens und der Produktversion, sodass die folgende Zuweisung innerhalb des Eigenschaftendialogs vorzunehmen ist: ProductVersion=$(Version);ProductName= $(Name);SourceFolder=$(Folder). Zu beachten ist, dass diese Festlegung für alle Konfigurationen, also für die Debug- und die Release-Version, erfolgt, sodass eine unabhängige Wertzuweisung von der Kommandozeile aus möglich ist. MSBuild kann dann das entsprechende Setup parametergesteuert erzeugen, etwa wie mit den beiden folgenden Aufrufen: msbuild.exe setup.wixproj /p:configuration=release; Version=1.0; Name="Demo"; Folder=D:\Demo\Bin\Release msbuild.exe setup.wixproj /p: Configuration=Debug;

4 Version=1.0; Name="Demo (Debug)"; Folder= D:\Demo\Bin\Debug [Abb. 1] Präprozessorvariablen für MSBuild in den Projekteigenschaften. [Abb. 2] Aktionen im Build-Prozess. Dynamisches Installationslayout Der erste Schritt wäre damit geschafft und das Installationspaket erstellt. Für viele Anforderungen reicht eine solche Umsetzung aus. Aber es gibt Situationen, in denen ein höherer Abstraktions- und Automatisierungsgrad erreicht werden sollte. Die bisherigen Definitionen in dem WXS-Dokument verwendeten einen exakt festgelegten Satz von Ressourcen wie in Listing 1 die Dateien ImageViewer.exe und ImageViewer.pdb. Mitunter ist es aber nötig, Ressourcen in eine Installation zu integrieren, die beim Erzeugen der WIX-Quelldateien noch nicht verfügbar sind oder deren Umfang noch nicht feststeht. Es soll also erst zum Zeitpunkt des Build-Prozesses dynamisch festgelegt werden, welche Ressourcen dem Paket hinzuzufügen sind. Für die Anwendung aus Listing 1 könnte es sich um Bilder handeln, die erst während des Build-Prozesses ermittelt und bei der Installation im Ordner MyPicturesFolder abgelegt werden. Bei Installationssystemen, die nicht auf der WiX-Technologie basieren, ist eine solche Anforderung relativ einfach umsetzbar, denn letztlich handelt es sich um eine XCopy-Aktion, die den Inhalt eines Ordners oder Archivs in das Zielverzeichnis transportiert. Mit dem Windows Installer ist diese Anforderung etwas schwieriger umzusetzen. Das liegt daran, dass der Installer alle Ressourcen in einer eigenen Ablage registriert. Dies ist erforderlich, da nur hierdurch das transaktionale Installationsverhalten, die vollständige Deinstallation und die automatische Reparatur fehlender Ressourcen zu erreichen sind. Windows Installer XML enthält dazu das Tool heat.exe. Hierbei handelt es sich um einen sogenannten Harvester, also ein Tool zum Sammeln von Informationen für die Installation. Denken Sie zum Beispiel an ein einfaches Installationspaket, das lediglich Dateien installieren soll. Hierzu muss zunächst ein WXS-Dokument erzeugt werden, das die entsprechenden Dateien definiert. Dazu ist eine Komponente zu erzeugen und dieser Komponente die Datei mit den entsprechenden Metainformationen zuzuordnen. Das bedeutet auch, dass sich in Abhängigkeit vom Dateityp ein unterschiedliches Vorgehen ergibt. Handelt es sich beispielsweise um eine COM-Komponente, müssen die zugehörigen Registrierungsinformationen ebenfalls ausgelesen und im WXS-Dokument abgelegt werden; handelt es sich um eine.net-assembly, sind die spezifischen Assembly-Attribute dem Element <File> hinzuzufügen; handelt es sich um eine Datei mitversionsangaben, müssen diese übernommen werden. Verfügt die Datei über keine Versionsdaten, ist ein Hash zu berechnen und der entsprechenden Tabelle zuzuordnen. Es wird deutlich, dass der Aufwand zum Ermitteln dieser Informationen und deren Speicherung im WXS-Dokument nicht zu unterschätzen ist. An dieser Stelle kommt heat.exe ins Spiel. Das Tool ermittelt automatisch alle erforderlichen Informationen und erstellt daraus ein WXS-Dokument. Hierbei ist es möglich, die Informationen für eine einzelne Datei oder ein komplettes Verzeichnis abzurufen. Für die erwähnten Bilder zu Listing 1 bedeutet dies, dass mit heat.exe alle Bilder eines entsprechenden Verzeichnisses ermittelt werden und die gewonnenen Informationen einem neuen WXS-Dokument angefügt werden. Das heißt, dass das bisher konstruierte WXS-Dokument aus Listing 1 weiterhin die betreffenden statischen Elemente enthält und diese zum Anfügen der dynamischen Elemente nicht mehr modifiziert werden sollten. Die variablen Elemente sind einem separaten Dokument hinzuzufügen, das vom Hauptdokument referenziert wird. Eine solche Referenzierung ist unter anderem durch das Element <ComponentRef> möglich, das auf das Identifizierungsmerkmal einer Komponente verweist. Da derwindows Installer immer komponentenorientiert arbeitet, werden die Ressourcen in einer oder mehreren Windows- Installer-Komponenten organisiert. Die Schwierigkeit liegt nun darin, bereits beim Erstellen des Hauptdokuments die Referenz auf die Komponente(n) zu erstellen, denn zu diesem Zeitpunkt sind die dynamischen Ressourcen ja noch nicht verfügbar. Somit lässt sich noch nicht sagen, wie viele Windows-Installer-Komponenten die dynamischen Ressourcen aufnehmen und wie diese bezeichnet werden. Abhilfe schafft ei

5 _ Automatisches Erstellen von Installationsprogrammen mit MSBuild & Co. Listing 2 ne spezielle Gruppierungsfunktion, die als Komponentengruppe <ComponentGroup> bezeichnet wird. Eine solche Gruppe lässt sich über das Element <ComponentGroup- Ref> referenzieren. Bei der Verwendung von heat.exe werden sämtliche ermittelten Komponenten einer Komponentengruppe angefügt, deren Name frei wählbar ist. Somit wird es möglich, bereits beim Erstellen des Hauptdokuments einen Verweis auf diese Komponentengruppe einzubinden, ohne dass der Inhalt dieser Gruppe zu diesem Zeitpunkt bereits feststeht. In Listing 1 findet sich im Zuordnungsbereich der Komponenten zu den Merkmalen der Verweis auf die Komponentengruppe CG Images. Hierdurch wird die nachträgliche Integration dynamischer Komponenten möglich, denn letztlich muss diese Bezeichnung nur bei der automatisierten Konstruktion des neuen Dokuments angegeben werden. Mit der folgenden Befehlszeile werden die im Ordner d:\images enthaltenen Dateien ermittelt und die erforderlichen Informationen in eine Datei mit der Bezeichnung images.wxs übertragen: heat.exe dir "d:\images" -out images.wxs -gg -cg CG Images -dr MyPicturesFolder -srd -suid Hierbei wird eine Komponentengruppe mit der Bezeichnung CG Images verwendet. Die Dateien werden so konfiguriert, dass sie bei der Installation im Verzeichnis MyPicturesFolder gespeichert werden. Die so konstruierte Datei ist in Listing 2 dargestellt. Sie muss letztlich nur noch dem Visual-Studio-Projekt angefügt werden, damit sie im Build berücksichtigt wird. Da die WIXPROJ-Projektdatei jedoch nicht nachträglich modifiziert werden soll, sollte das Projekt bereits über eine Dummy- Datei verfügen, deren Aufbau in Listing 3 zu finden ist. Diese Datei enthält im Wesentlichen nur die Definition der Komponentengruppe. Im Hauptdokument lässt Ein mit heat.exe dynamisch erzeugtes XML-Fragment. <?xml version="1.0" encoding="utf-8"?> <Wix xmlns=" <Fragment> <DirectoryRef Id="MyPicturesFolder" /> </Fragment> <Fragment> <ComponentGroup Id="CG Images"> <Component Id="Desert.jpg" Directory="MyPicturesFolder" Guid="{11C1DE87-A F-EA85F }"> <File Id="Desert.jpg" KeyPath="yes" Source="SourceDir\Desert.jpg" /> </Component> <Component Id="Lighthouse.jpg" Directory="MyPicturesFolder" Guid="{D9CAB48D-4CA0-4D3C-B39D-3336D872593D}"> <File Id="Lighthouse.jpg" KeyPath="yes" Source="SourceDir\Lighthouse.jpg" /> </Component> </ComponentGroup> </Fragment> </Wix> Listing 3 Dummy-Datei zum Referenzieren durch heat.exe. <?xml version="1.0" encoding="utf-8"?> <Wix xmlns=" <Fragment> <ComponentGroup Id="CG Images"> </ComponentGroup> </Fragment> </Wix> sie sich durch das folgende Element einbinden: <ComponentGroupRef Id="CG Images"/> Auch wenn die dynamischen Elemente noch nicht ermittelt sind, lässt sich das Projekt nun erstellen, denn die Referenzen können aufgelöst werden. Mit heat.exe ist es sehr einfach möglich, variable Informationen in das Installationslayout einzubinden und es in einen automatischen Build-Prozess umzusetzen, da lediglich ein Befehlszeilenaufruf nötig ist. Wird der folgende Aufruf in den Projekteigenschaften als Präbuildereignis eingefügt, werden vor dem Erzeugen des Installationspakets die dynamischen Ressourcen ermittelt: heat.exe dir "d:\images" -out "$(ProjectDir)images.wxs" -gg -cg CG Images -dr MyPicturesFolder -srd -suid Das Ergebnis wird in die Datei images.wxs übertragen, die zum Visual- Studio-Projekt gehört und somit im Build berücksichtigt wird. Als Alternative zu dem Befehlszeilenaufruf besteht auch die Möglichkeit, auf vorgefertigte MSBuild-Tasks zuzugreifen, die Windows Installer XML zur Verfügung stellt. Der HeatDirectory-Task etwa ermittelt die Dateien eines Ordners. Weitere Tasks sind HeatFile und HeatProject. Unabhängig von der Art und Weise, wie die Dateien ermittelt werden, ist die erzeugte Projektdatei kompatibel mit MS- Build. So ist es möglich, ein Projekt auch auf einem PC zu erstellen, auf dem sich kein Visual Studio befindet. Allerdings muss die Tool-Sammlung Windows Installer XML vorhanden sein. Probleme mit Updates Aber es ist nicht alles Gold, was glänzt, denn heat.exe weist auch Schwachpunkte auf, welche die Verwendung in einigen Update-Fällen unmöglich machen. Dabei ist zu beachten, dass bei minimalen Aktualisierungen also bei Small und Minor Upgrades gewisse Richtlinien einzuhalten sind. So ist es zwar möglich, dem Aktualisierungspaket eine neue Windows-Installer-Komponente hinzuzufügen. Der entgegengesetzte Weg jedoch, also das Entfernen einer Komponente, verstößt gegen diese Richtlinien und zwingt dazu, ein Major Upgrade zu erstellen. Hieraus folgt, dass sich Windows-Installer-Patches der jüngsten Generation nicht mehr erzeugen las

6 sen, denn diese basieren immer auf einem Small oder einem Minor Upgrade [3]. Um das Problem zu verifizieren, genügt es, zwei WXS-Dateien des identischen Ordnerinhalts mit heat.exe zu erstellen und diese zu vergleichen. Dabei zeigt sich, dass die Dateien bei den GUIDs der Komponenten abweichen was aber auch nicht verwunderlich ist, denn heat.exe erzeugt die GUIDs bei jedem Aufruf neu. Da diese GUIDs die ComponentId jedoch das Identifizierungsmerkmal für den Windows Installer darstellen, kommt der Installer zu dem Schluss, dass eine Komponente aus dem Installationslayout entfernt und eine neue hinzugefügt wurde. Und das bedeutet letztlich, dass die Richtlinien für minimale Aktualisierungen verletzt worden sind. Hieraus lässt sich ableiten, dass heat.exe nur bedingt zum Ermitteln dynamischer Elemente taugt. Ist abzusehen, dass keine Updates erforderlich werden oder dass diese nur in Form von Major Upgrades bereitgestellt werden, kann heat.exe durchaus verwendet werden. Andernfalls sollten Sie auf ein anderes Tool ausweichen. Paraffin 3.1 gehört nicht zur Tool-Sammlung Windows Installer XML, sondern steht unter [4] zum kostenlosen Download zur Verfügung. Es handelt sich um eine in bestimmten Bereichen erweiterte Version von heat.exe, die auch Updates berücksichtigt. Das Vorgehen gleicht dem bei heat.exe, wobei sich die Parameterbezeichnungen unterscheiden: 1/2 hoch 104x297 paraffin.exe -dir "d:\images" images.wxs -groupname CG Images -dirref MyPicturesFolder nrd Das Ergebnis entspricht der mit heat.exe erzeugten Datei, sodass die Referenzen seitens der Basisdatei keine Änderungen erfordern. Der Vorteil von Paraffin liegt aber klar bei Updates. Hier ist es möglich, die bereits erzeugte Datei als Vorlage zu verwenden und den Ordner erneut zu analysieren. Folgender Befehlszeilenaufruf ist dafür zu verwenden: paraffin.exe -update images.wxs Es wird deutlich, dass lediglich eine Referenz auf die bereits erzeugte Datei erforderlich ist. Das Ergebnis dieses Aufrufs ist eine neue Datei mit der Endung PARAFFIN; in dem Beispiel wird die Datei images.paraffin erzeugt. Ressourcen, die bereits in der ursprünglichen Fassung vorhanden waren, übernimmt das Tool unverändert. Das bedeutet, dass die ComponentIds nicht neu generiert, sondern beibehalten werden. Dies entschärft das Problem der entfernten Komponenten, beseitigt es aber nicht vollständig. Denn es ist ja möglich, dass eine Ressource im Aktualisierungspaket tatsächlich nicht mehr vorhanden sein soll, sie also gar nicht mehr in dem Ordner der Quelldateien vorhanden ist. Das führt wiederum dazu, dass die Voraussetzungen für minimale Aktualisierungen nicht mehr gegeben sind. Die Schwierigkeit bei der Verwendung der dynamischen Elemente ist jedoch, dieses Problem zu identifizieren. Fehlende Komponenten feststellen Mithilfe der Systemrichtlinie EnforceUpgradeComponentRules ist es möglich, eine entfernte Komponente zu ermitteln. Dazu ist die Systemrichtlinie zu aktivieren, das ursprüngliche Paket zu installieren und anschließend die Update-Installation zu starten. Es ist aber auch möglich, anstelle der Systemrichtlinie die Windows-Installer-Eigenschaft MSIENFORCEUPGRADECOMPONENTRULES

7 _ Automatisches Erstellen von Installationsprogrammen mit MSBuild & Co. [Abb. 3] So präsentiert sich das Beispielprojekt in FinalBuilder. handelt. Dennoch sind im Build-Vorgang für das jeweilige Softwareprodukt weitere Aktivitäten erforderlich, von denen Abbildung 2 einige aufführt. Es ist natürlich möglich, diese Aktivitäten manuell in eine Projektdatei für MSBuild einzubinden. Einfacher ist es jedoch, auf entsprechende Anwendungen wie beispielsweise FinalBuilder [5] auszuweichen. Der große Vorteil dieses Tools liegt in der großen Flexibilität, da es für nahezu jede Aktion vorgefertigte Bausteine bietet. So sind auch Anforderungen wie das automatisierte Brennen der Ausgaben auf eine CD oder DVD sehr einfach umsetzbar. FinalBuilder stellt ebenfalls eine grafische Oberfläche zur Konstruktion des Build- Projekts zur Verfügung, sodass sich der Aufwand stark reduziert. Besonders herauszustellen sind die Mechanismen des Tools, die über Erfolg oder Misserfolg der jeweiligen Aktivitäten informieren oder auch die weiteren Aktivitäten bei Misserfolgen regeln. Ein solches Werkzeug bietet eine Vielzahl von Vorteilen und erhöht letztlich die Qualität des Produkts. beim Aufruf der Installation zu setzen. Sollte eine Komponente im Aktualisierungspaket fehlen, bricht die Installation mit dem Fehler 2771 ab und fügt dem Installationsprotokoll diese Angabe hinzu: MSI (s) (F0:68) [17:24:45:615]: SELMGR: ComponentId '{332C7990-C FEF834AB}' is registered to feature 'Application', but is not present in the Component table. Removal of components from a feature is not supported! DEBUG: Error 2771: Upgrade of feature Application has a missing component. Es ist zu beachten, dass eine Testinstallation immer mit dieser Einstellung arbeiten sollte, denn sie führt zu einem höheren [Abb. 4] Der FinalBuilder- Editor zum Bearbeiten von Variablen. Qualitätsstandard, und böse Überraschungen bleiben aus. Wird ein Aktualisierungspaket ausgeliefert, bei dem eine Komponente entfernt wurde, und ist auf dem Kundensystem diese Systemrichtlinie aktiv, schlägt die Installation fehl, was kein gutes Licht auf das Produkt wirft. Zusätzliche Aktivitäten Die bisherigen Ausführungen waren ausschließlich auf das Installationspaket fokussiert und haben Mechanismen aufgezeigt, um die Erzeugung individuell zu beeinflussen, ohne die Quelldateien zu verändern. Das ist jedoch nur die halbe Miete, wenngleich es sich um die wesentlichen Faktoren seitens des Installationspakets Verwenden von FinalBuilder Zur Demonstration sollen die zuvor erläuterten Projekte dienen, die diesmal mit FinalBuilder erzeugt und weiterverarbeitet werden. Die anfallenden Aktionen erheben keinen Anspruch auf Vollständigkeit, sondern sollen nur die Möglichkeiten und den Ablauf näherbringen. Das Beispielprojekt definiert die folgenden Phasen, die sich auch im Projektbaum in Abbildung 3 wiederfinden: Aktualisieren der Versionsdaten, Erstellen der Assemblies, Ausführen von Unit-Tests, Erstellen des Setups und Validieren des Installationspakets, Brennen des Setups auf CD/DVD, Löschen der temporären Dateien. Bevor es mit den Aktionen zur Aktualisierung der Versionsinformationen losgeht, sind zunächst einige Variablendeklarationen erforderlich. Diese dienen einerseits zum dynamischen Steuern des Ablaufs; darüber hinaus legen sie die Konfiguration des Projekts fest. Die Variablen werden über den in Abbildung 4 dargestellten Editor erfasst und verwaltet. Für das Beispielprojekt wurden die in Tabelle 1 aufgeführten Variablen definiert. Im Projektbaum wird zu Beginn die Variable %ISAUTOBUILD% geprüft. Hierbei handelt es sich um eine von FinalBuilder

8 automatisch erzeugte Systemvariable. Sie enthält den Wert True, falls das Projekt automatisch über den folgenden Befehlszeilenaufruf oder über die Konsolenanwendung von FinalBuilder gestartet wird: FinalBuilder6.exe /r <Projektdatei> Wurde der Startbefehl hingegen aus der Benutzeroberfläche gegeben, enthält die Variable %ISAUTOBUILD% den Wert False. In diesem Fall wird ein Dialogfeld angezeigt, in dem die Eigenschaften zur Ablaufsteuerung individuell konfigurierbar sind. Im nächsten Schritt geht es um die Aktualisierung derversionsinformationen. Zu Beginn dieses Abschnitts wird ein Property- Set definiert. Hierunter ist eine Zusammenfassung von einzelnen Eigenschaftswerten zu verstehen. In diesem Fall handelt es sich um ein PropertySet vom Typ einer.net- AssemblyNumber, das über AppVersion symbolisiert ist. Das bedeutet, dass diesem PropertySet eine.net-versionsangabe zugewiesen werden kann. Das PropertySet ermöglicht den Zugriff auf die einzelnen Versionselemente, also auf die Major, Minor, Build- und Revisionsversion [6]. Es wird somit zunächst ein PropertySet definiert, dem anschließend eine Versionsnummer zugewiesen wird. Hierzu wird die Datei AssemblyInfo.cs des Beispielprojekts referenziert, bei der letztlich das Attribut AssemblyVersion ausgewertet und übertragen wird. Im folgenden Schritt wird die Eigenschaft RevisionVersion um den Wert 1 erhöht und die referenzierte Datei mit dieser neuenversionsangabe aktualisiert; die hier gewählte Vorgehensweise soll die Möglichkeiten zum Zugriff auf die Versionsangaben demonstrieren. Die von FinalBuilder für diese Zwecke bereitgestellten Funktionen sind äußerst mächtig und lassen nahezu keine Wünsche offen. Nach dem Aktualisieren der Versionsdaten kann die Anwendung erzeugt werden. Hierzu wird die Microsoft Build Engine verwendet, der die CSPROJ-Datei und einige individuelle Konfigurationseinstellungen zuzuweisen sind. So erhält die Präprozessorvariable Configuration den Inhalt der definierten Variablen %Config% und die Präprozessorvariable OutputPath den Wert %FBPROJECTDIR%\Output. Bei der Variablen %FBPROJECTDIR% handelt es sich wieder um eine Systemvariable, die FinalBuilder automatisch festlegt. Diese Variable verweist auf das Verzeichnis, in dem sich die FinalBuilder-Projektdatei mit der Endung FBZ6 befindet. Hieraus folgt, dass Tabelle 1 Definierte Variablen des FinalBuilder-Projekts. Variable Standardwert Beschreibung Config Debug Konfiguration der Projekte (Debug oder Release). DoBurn False Dateien nach Fertigstellung auf CD/DVD brennen. DoTests True Unit-Tests ausführen. DoValidate True Validierung des Installationspakets ausführen. InstallerName Setup.msi Name des Installationspakets. ParaffinFileExist Das Vorhandensein einer Datei prüfen. ProgramName Image Viewer Name des Programms. die erzeugte Assembly im Unterverzeichnis Output gespeichert wird. Als Nächstes definiert das Beispiel Unit- Tests. Zuerst wird die Variable %DoTests% ausgewertet, um festzustellen, ob dies auch gewollt ist. Anschließend wird der Unit-Test gestartet, wozu Referenzen auf die Assemblies und die NUnit-Projektdateien gesetzt werden. Zusätzlich zu den Aktionen zur Verwendung von NUnit enthält FinalBuilder auch Aktionen zur Verwendung von MSTest, sodass Tests auf vielfältige Art möglich sind. Nach dem Testen der Anwendung kann das Installationspaket erstellt werden. Dieses ist im Wesentlichen identisch mit der Erstellung der Anwendung, da die WIX- PROJ-Datei kompatibel mit MSBuild ist und somit die gleiche Aktion zu verwenden ist. Dazu kommen allerdings noch einige zusätzliche Optionen, die eine höhere Flexibilität beim Design des Installationslayouts ermöglichen. Zu Beginn sind die zusätzlichen Dateien mit paraffin.exe zu ermitteln, wie es bereits weiter oben erläutert wurde. Zunächst wird geprüft, ob im WiX-Projektverzeichnis die Datei mainimages.wxs vorhanden ist. Falls nicht, wird sie erstellt, wozu Paraffin mit den Optionen zum Erzeugen der Basisdatei aufgerufen wird. Diese Basisdatei dient dann als Referenz und Paraffin wird zusätzlich dazu veranlasst, eine Aktualisierungsdatei anzulegen. Der Vorteil dieses Ansatzes liegt darin, dass er Updates wirkungsvoll berücksichtigt, da die Basisdatei nur einmal entsteht. So bleiben die Identifizierungsmerkmale der Komponenten erhalten. Für das eigentliche Installationsprogramm ist nur noch die Update-Datei, also die Datei mit der Endung PARAFFIN, relevant und erforderlich. Diese wird in images.wxs umbenannt. Durch diese Umbenennung ist sie automatisch Teil des Projekts, da es bereits über eine Dummy- Datei mit dieser Bezeichnung verfügt hat. Bevor das Setup erstellt werden kann, ist noch der Dateiname so anzupassen, dass dieser Rückschlüsse auf die Version und die Konfiguration zulässt. Der Aufruf von MSBuild erfolgt wiederum mit einigen Eigenschaften, die an den Präprozessor weitergeleitet werden. Dazu gehört auch die zu Beginn des FinalBuilder-Projekts ermittelte und aktualisierte Versionskennung, sodass das Installationspaket über die gleiche Version verfügt wie die Anwendung. Nachdem das Installationspaket erstellt wurde, wird es noch mit Authenticode signiert, wie es diewindows-logo-richtlinien fordern. Darüber hinaus ermöglicht die Signatur in Verbindung mit dem Element <PackageCertificates> des WXS-Dokuments eine effizientere Anzeigeform des UAC-Dialogs bei Transaktionen mehrerer Pakete [7]. Das fertige Paket ist im Anschluss daran noch zu prüfen, falls die Variable %DoValidation% entsprechend gesetzt wurde. Dabei handelt es sich um eine ICE-Validierung [8] mit dem Tool msival2.exe; es ist Teil des Windows-SDKs. Es ist natürlich auch möglich, im Rahmen der Erstellung durch Windows Installer XML automatisch zu validieren, was etwas einfacher ist. Das hier gezeigte Vorgehen soll lediglich darauf hinweisen, dass FinalBuilder über Aktionen zum Referenzieren von Tools aus dem Windows-Installer-SDK verfügt. Es ließen sich auch noch Prozeduren einbinden, die eine Testinstallation einrichten. Dies stellt kein Problem dar, denn FinalBuilder enthält auch dafür die entsprechenden Aktionen. Im Prinzip ist es das gewesen die Anwendung und das Setup sind nun erstellt und getestet. Was noch bleibt, sind zusätzliche Aktivitäten und Aufräumarbeiten. Die Aufräumarbeiten stehen natürlich am Ende. Sie säubern die Projekte und entfernen nicht mehr benötigte Dateien. Die zusätzlichen Aktivitäten können sehr vielschichtig sein; üblicherweise zielen sie

9 _ Automatisches Erstellen von Installationsprogrammen mit MSBuild & Co. jedoch auf das erstellte Produkt, in diesem Fall also auf das Installationsprogramm. Letztlich geht es immer um die Frage, was nun mit dem Installationsprogramm geschehen soll. Denkbar wäre das Kopieren auf ein Netzlaufwerk, das Bereitstellen im Inter- oder Intranet oder das Brennen auf CD/DVD. Das vorliegende Beispiel packt das Installationspaket zunächst in eine ZIP-Datei und brennt beide Dateien anschließend auf eine CD/DVD. Team Foundation Server Der Team Foundation Server nimmt in aktuellen Entwicklungs- und Build-Umgebungen einen immer höheren Stellenwert ein, sodass er hier nicht außen vor bleiben darf. Das wichtigste und interessanteste Merkmal des Servers ist zweifelsohne der Team-Build. Einfach ausgedrückt handelt es sich um ein Build-Management-System für Softwareentwicklungsprojekte, das flexibel und erweiterbar ist. Die Erweiterbarkeit ermöglicht es, mit FinalBuilder erzeugte Projekte in das Build-System zu integrieren und unter Kontrolle des Team Foundation Servers auszuführen. Zur Realisierung ist zunächst eine neue Build-Definition zu erzeugen; dazu steht im Kontextmenü des Team Explorers der entsprechende Befehl zur Verfügung, wie er in Abbildung 5 zu sehen ist. Sie startet Final- Builder und erzeugt automatisch ein neues Projekt mit einer rudimentären Implementierung. Es ist natürlich auch möglich, bestehende FinalBuilder-Projekte einer bereits vorhandenen Build-Definition anzufügen. Hierzu ist die jeweilige Definition zu editieren. In dem entsprechenden Dialog lassen sich neue FinalBuilder-Projekte erstellen, existierende hinzufügen oder modifizieren. Darüber hinaus können von hier [Abb. 5] So ist eine neue Build-Definition im Team Foundation Server zu erstellen. aus die Optionen für die einzelnen Final- Builder-Projekte verändert werden. In einem bereits existierenden FinalBuilder-Projekt, das nun unter Kontrolle des Team Foundation Servers ausgeführt werden soll, sind keine spezifischen Anpassungen nötig. Wird jedoch ein solches Projekt in diesem Kontext verwendet, bleiben viele Funktionen des Team Foundation Servers ungenutzt. Es ist sinnvoll, das Projekt so anzupassen, dass der Zugriff auf Eigenschaften der Build-Instanz möglich ist. Hiermit sind Eigenschaften wie das Ausgabeverzeichnis oder das Verzeichnis der Quelldateien gemeint, die innerhalb des Team Foundation Servers konfiguriert werden. Um den Zugriff auf die jeweilige Build-Instanz und ihre Parameter zu ermöglichen, ist dem FinalBuilder-Projekt die Aktion Get Team Foundation Build Parameters hinzuzufügen. Beim Erstellen einer neuen Projektdatei über die zuvor dargestellte Integration in den Team Foundation Server werden diese Aktion und einige Variablendefinitionen automatisch in das Projekt übernommen. Die Aktion stellt mehrere nützliche Optionen zur Verfügung. Zunächst lässt sich hier das Mapping zwischen Eigenschaften und Variablen konfigurieren. Erfolgt ein Team-Build, werden einige Eigenschaften des Team Foundation Servers an FinalBuilder übertragen. Die Eigenschaften können nun auf Variablen des FinalBuilder-Projekts abgebildet und im Projekt benutzt werden. Die Eigenschaft DropLocation des Servers gehört beispielsweise dazu. Sie ist innerhalb der Build-Definition des Team Foundation Servers zu konfigurieren und zeigt auf das Verzeichnis, in dem die Build- Ausgaben abgelegt werden sollen. In der dargestellten Aktion kann nun festgelegt werden, auf welche Variable des FinalBuilder-Projekts diese Eigenschaft abgebildet werden soll. Der Standardwert ist dievariable %DropShare%, die im weiteren Projektverlauf für die Kennzeichnung der Zielverzeichnisse verwendet werden kann. Das ganze Szenario kann natürlich nur funktionieren, wenn die Ausführung des Projekts aus dem Team-Build heraus erfolgt. Diese Voraussetzung lässt sich ebenfalls mit dieser Aktion prüfen und die Ausführung gegebenenfalls abbrechen. Beim Festlegen der Build-Definition ist für die FinalBuilder-Projekte ebenfalls bestimmbar, ob und in welches Protokoll Build-Informationen übertragen werden sollen. In Bezug auf die erläuterte Aktion bedeutet das, dass dem Protokoll die tatsächlichen Eigenschaftswerte des Team Foundation Servers und das Mapping auf die Variablen des FinalBuilder-Projekts hinzugefügt werden. Erfolgt die Ausgabe in das Protokoll des Team-Builds, finden sich dort die folgenden Einträge: [ Get Team Foundation Build Parameters ] Team Server URL : (saved to variable TeamServer) Team Project Name : WIX (saved to variable TeamProject) Team Build Id : dotnetpro_ (saved to variable BuildId) Platform : Any CPU (saved to variable BuildPlatform) Flavor : FinalBuilder (saved to variable BuildFlavor) Deployment Share : \\localhost\drops\dotnetpro_ (saved to variable DropShare) Local Build Directory : C:\Documents and Settings\TFSBUILD\Local Settings\Temp\WIX\dotnetpro\Sources (saved to variable SourceRoot) Auf diese Weise lässt sich das Zusammenspiel zwischen Team Foundation Server und FinalBuilder definieren und optimieren. FinalBuilder enthält darüber hinaus noch eine Vielzahl von Aktionen, die auf Funktionen des Team Foundation Servers zielen. So finden sich Aktionen zum Verwalten vonwork Items und zurverwendung des Quellcodesystems. Die hierdurch zur Verfügung stehenden Möglichkeiten sind sehr mächtig und bieten genug Stoff für einen neuen Artikel. [jp] [1] Windows Installer XML (WiX) Toolset, [2] Andreas Kerl, Auf zu neuen Ufern, Installationsroutinen mit Windows Installer XML 3, dotnetpro 9/2007, Seite 66ff., [3] Andreas Kerl, Öfter was Neues, Lifecycle- Management mit dem Windows Installer, dotnetpro 5/2008, Seite 78ff., [4] Paraffin 3.1, [5] FinalBuilder, [6] Andreas Kerl, Lizenz zum Laden, Bindungsrichtlinien bei der Verwendung von.net- Assemblies, dotnetpro 1/2010, Seite 86ff., [7] MSDN, Multiple-Package Installations, [8] Andreas Kerl, Installations-TÜV, Windows Installer: Qualitätssicherung und Troubleshooting, dotnetpro 6/2008, Seite 44ff.,