Neu in TFS 2018: Erweiterungen der Pull Requests

Damit der Code einer Software eine hohe Qualität aufweist sind regelmäßige Reviews Pflicht. Pull Requests (PR) bieten für Reviews eine tolle Plattform. Sie stellen eine Art Benachrichtigung dar, in der ein Verantwortlicher Anton eine andere Entwicklerin Berta darum bittet den neuen Code in den bestehenden zu integrieren. Entwicklerin Berta kann nun Feedback liefern und eine Diskussion beginnen, woraufhin Anton den Code wieder ändert, um schlussendlich wiederum von Berta abgesegnet zu werden. Feedback zu Code wird dabei in Form von Kommentaren hinterlassen.  Auch bei den bereits vorgestellten Git Forks, welche nun neu in TFS 2018 dazu gekommen sind, kommen Pull Requests zum Einsatz um bspw. Erweiterungen von außen in das Projekt zu integrieren.

Mit TFS 2018 kommen nun einige Neuerungen in den Bereich der Pull Requests, welche die Benutzbarkeit dieser deutlich erhöhen. Wir stellen Ihnen die Wichtigsten vor.

WiX Heat XSL Transformation

Mit Hilfe von Heat lässt sich die Fragmenterzeugung, welche ein Hauptbestandteil eines WiX Installers ist, automatisieren. Dies wurde bereits im Beitrag Automatische Fragmenterzeugung mit Heat gezeigt. Was aber, wenn die ein oder andere Datei im Installationsvorgang nicht kopiert werden soll oder der Component bzw. dem File noch Attribute hinzugefügt werden müssen? Das erzeugte Fragment manuell zu verändern ist nicht sehr ratsam, da dies bei jedem Durchlauf von Heat überschrieben wird.
Hier kommen XSL Transformationen zum Einsatz, welche dem Heat Vorgang angehängt werden können. Mit Hilfe einer solchen Transformation lässt sich die automatisierte Fragment Datei abschließend bearbeiten.

WiX: Automatische Fragmenterzeugung mit Heat

Das WiX Toolset ist ein mächtiges Werkzeug um Installationsroutinen mit Hilfe von XML zu erzeugen.

Herzstück eines WiX Projektes ist das Product Element. Innerhalb diesem werden die Elemente der Installationsroutine definiert. Um außerhalb des Product Elements Installationselemente wie Components oder Directorys zu definieren wird ein Fragment Element benötigt, in welchem die einzelnen Elemente angelegt werden. Für die Übersichtlichkeit ist es daher sinnvoll eine neue Fragmentdatei außerhalb des Product Elements zu erzeugen.

Wer seine WiX Fragmente von Hand erzeugt, wird schnell merken, dass diese mit jeder Erweiterung der Software erneut angepasst werden müssen. Vor allem bei stetig wachsender Software kann dies zu Problemen führen. Nicht zuletzt, weil Fragmente gerne mal zu hunderten XML-Zeilen heranwachsen.
Schnell wird die Integration einer neuen DLL vergessen und die Anwendung startet nach Installation nicht.

An dieser Stelle ist die Frage angebracht ob man das Problem nicht automatisiert lösen kann?

Die Antwort ist: ja, man kann!