Frustfreie Web.config auch im Team

Eine sehr nützliche Funktion im Visual Studio und MSBuild ist die Möglichkeit, bei der Veröffentlichung von Webseiten die Web.config entsprechend der gewählten Zielkonfiguration automatisch anpassen zu lassen. Der Vorgang nennt sich Transformation und beschreibt im Prinzip nichts weiter als anhand von Transform-Dateien die Web.config zu verändern. Das Prinzip ist identisch mit der bekannten Xml Transformation mittels XSLT (in Visual Studio heißt nur alles wieder mal anders).

Während das Konzept beim Web-Publishing bereits sinnvoll ist (um z.B. für Debug, Release, Stage, etc. unterschiedliche Konfigurationen parat zu haben), wäre der Einsatz während der Entwicklung selbst allerdings genauso praktisch. Beispielsweise könnten einzelne Teammitglieder unterschiedliche lokale Entwickler-Datenbankinstanzen haben, die sich auf die ConnectionStrings in der Web.config auswirken. Das Problem, das daraus i.d.R. entsteht, ist, dass jeder Entwickler die Web.config bei sich lokal anpasst und dadurch auscheckt. Sollte sie dann “aus Versehen” mal mit eingecheckt werden, klappt bei anderen Entwicklern im Zweifelsfall die Datenbankverbindung nicht mehr, sobald sie ihren Workspace aktualisieren. Im schlimmsten Fall werden dadurch Basisänderungen an der Web.config überschrieben wenn man nicht aufpasst.

Die Lösung für dieses Problem wäre, jedem Entwickler eine eigene Transform-Datei bereitzustellen und dafür zu sorgen, dass personenabhängige Einstellungen ausschließlich darin stattfinden. Dazu muss die Web.config allerdings zur Compilezeit generiert werden und darf zudem nicht mehr Teil der Quellcodeverwaltung sein.

Wie das im Einzelnen funktioniert zeigt folgende Schritt für Schritt Anleitung:

Das Publishing Target und die Config Transformation lokal konfiguriert

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