Und hier geschieht ein Wunder! - Installer bauen auf der #dwx14

Chef: “Und Schmitt? Ist unser neuer Quanten-Warp-Dimensions-Taschenrechner für Windows Desktop fertig?

Schmitt: “Ja Chef! Wenn Sie ihn testen wollen, müssen Sie nur das Multiphasen SDK installieren, sämtliche Dateien in das Programme Verzeichnis kopieren und kurz die 47 Registry Strings anlegen, die ich Ihnen gleich maile. Die Datenbankverbindung konfigurieren Sie dann in der app.config Datei, und in der…

Chef: “Halt! Stop! Das geht so nicht! Das muss automatisiert werden, warum haben wir denn keinen Installer?

projektplanungGenau jetzt stellt sich die Frage, wie denn nun eigentlich dafür Sorge getragen wird, dass unsere zahlenden Kunden auch möglichst bequem dazu in die Lage versetzt werden, unsere neuste Software einzusetzen. Der Installer ist hier ein essentieller Projektbestandteil, der nur zu gerne vernachlässigt wird und gerne auch erst viel zu spät eingeplant wird.

Beim ersten Projekt stellt sich dann auch noch die Frage, wie man dies überhaupt realisieren kann…

- Selber ein Programm entwickeln, dass die Arbeit durchführt? Wohl kaum. Der Aufwand wäre deutlich zu hoch.

- Drittanbieter-Software wie bspw. InstallShield für die Erstellung verwenden? Schon besser, bringt aber Lizenzkosten mit sich und ist grade für komplexe Szenarien auch nur sehr komplex zu bedienen.

Wie wäre es ansonsten mit Windows Installer XML (WiX)? WiX basiert - wie der Name schon sagt - auf XML, jeder Entwickler wird sich hier also schnell zu Hause fühlen. Da es ein Open Source Produkt ist, fallen auch keine Lizenzkosten an, außerdem gibt es eine konsequente und zügige Weiterentwicklung. Und das Beste für uns Entwickler ist dabei, dass es Visual Studio Projekttemplates gibt, wodurch die Erstellung des MSI’s auf ein simples Kompilieren eben jenen Projektes reduziert wird! Der Buildprozess muss also nicht durch etwaige Aufrufe von Fremdsoftware aufwändig erweitert werden, um die Routinen zum Erstellen des MSI’s zu steuern.

Das die Erstellung eines Installers nichts mit Wundern zu tun hat, sondern tatsächlich für die meisten Fälle sogar relativ einfach zu realisieren ist, zeigen wir in der Session “Installer bauen leicht gemacht” auf der diesjährigen DWX!

Team Build, Web Applications und Verzeichnisstrukturen bei mehreren Projekten

Zu verschiedenen Theman lassen sich im Internet verschiedene Lösungsansätze finden. Was aber, wenn sich ein Thema zusammensetzt aus verschiedenen Puzzleteilen? Dann bleibt einem häufig nichts anderes übrig, als sich Lösungs-Puzzleteile zu verschaffen, die Verzahnung mit einer Feile passend zu schleifen und zu hoffen, dass das Gesamtbild noch dem entspricht, was auf der Spezifikation Verpackung (um der Analogie treu zu bleiben) abgebildet war.

Ziel ist es, eine Solution, die aus mehreren Projekten besteht, mittels Team Build automatisch bauen zu lassen und dabei in der Drop-Location nicht alle Binaries in einem einzigen Verzeichnis zu erhalten sondern in einer vorgegebenen Verzeichnisstruktur, die nach Projekten getrennt eine gewisse Übersichtlichkeit bietet. Neben Konsolen- und Winform-Anwendungen befinden sich darunter auch Web-Anwendungen. Daraus ergeben sich drei Teilprobleme:

  1. Bauen mehrerer Projekte innerhalb einer Solution
  2. Erhalt einer Verzeichnisstruktur
  3. Team Build und Web-Anwendungen

 

Während sich der erste Punkt leicht selbst herausfinden lässt, fängt es bei zweiterem an, kompliziert zu werden. Zum Glück hat Aaron Hallberg dazu eine Beschreibung parat, die aufzeigt, wie eine Verzeichnisstruktur erhalten werden kann. Seit Orcas (Team Foundation Server 2008) gibt es in der Team Build Konfiguration die Eigenschaft CustomizableOutDir, über die gesteuert werden kann, dass das Zielverzeichnis vom Benutzer konfiguriert wird:

<CustomizableOutDir>true</CustomizableOutDir>

 

In dem Moment, in dem diese Eigenschaft gesetzt ist, schleift Team Build die Standardeinstellung nicht mehr in die Eigenschaft OutDir durch. Jetzt muss sie entsprechend selbst in den Projekt-Dateien konfiguriert werden (wobei das jeweilige Projekt natürlich sowohl weiterhin lokal als auch über Team Build gebaut werden können muss):

<!--<OutputPath>bin\Debug\</OutputPath>-->

<OutputPath Condition=" '$(TeamBuildOutDir)'=='' ">bin\Debug\</OutputPath>

<OutputPath Condition=" '$(TeamBuildOutDir)'!='' ">$(TeamBuildOutDir)My\Custom\Structure\ProjectSolution</OutputPath>

 

Befindet sich unter den Projekten auch eine Web-Anwendung, dann scheitert Team Build in dem Moment an der Aufgabe, wenn die Web Deployment Projects hinzukommen. Hintergrund ist, dass die WDP die Ausgabe der Web-Anwendung im bin-Verzeichnis erwarten, sie nach dem Team Build Prozess dort aber nicht zu finden sind.

Aaron zeigt in seinem Blog ebenfalls, wie dieses Problem gelöst werden kann, wobei der V1-Ansatz auch mit Orcas funktioniert. Genau wie oben lässt sich dann über die OutputPath Eigenschaft in dem WDP-Projektfile die Verzeichnisstruktur für die Drop Location festlegen.

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS