Dr. Jochen Manns »

Archiv für den Monat: September 2014

Windows Installer und die Tabellen ServiceInstall und ServiceControl

Von | | , ,
Kommentare deaktiviert für Windows Installer und die Tabellen ServiceInstall und ServiceControl

Das Installationsprogramm von VCR.NET ist mit dem WiX Toolset 3.8 entwickelt, das letztlich Windows Installer Tabellen erstellt – auf einer insgesamt sehr eingängigen Philosophie. Zum Feintuning des Windows Dienstes VCR.NET Recording Service habe ich bisher Custom Actions verwendet und mir aber nun zum Ziel gesetzt, möglichst viel Standardfunktionalitäten des Windows Installers zu nutzen. Das hat zwar hier funktioniert, aber nur mit Haken und Ösen und nicht übertragbar auf größere Projekte. Trotzdem ein kleiner Erfahrungsbericht.

Die Installation des Dienstes erfolgt über die ServiceInstall Tabelle des Windows Installers – mit Hilfe des WiX Elementes ServiceInstall. An sich sehr einfach, einsichtig und elegant bis zu der Tatsache, dass die StartType Spalte eine Zahl ist und nicht dynamisch durch Properties des Installationsvorgangs berechnet werden kann. Ich möchte aber gerne dem Anwender die Möglichkeit geben, den Dienst auch mit manuellem Start (Vorgabe ist automatischer Start) zu installieren – etwa, wenn man sich nur den Quellcode anschauen möchte und nicht plötzlich nach dem nächsten Booten irgend einen Windows Dienst laufen haben will. Die scheinbar offizielle Lösung ist, für beide Varianten eigene Installer Komponenten mit unterschiedlichen Bedingungen zu hinterlegen. Zwar meckert dann die MSI Validierung (ICE30), was aber hier eine kontrollierte Warnung ist. Viel lästiger ist natürlich, dass man in der Tat eine doppelte Konfiguration hinterlegen muss – schade und fehleranfällig.

Auch wenn man das erst einmal als notwendiges Übel akzeptiert kommt direkt der nächste Rückschlag: auch in der ServiceControl Tabelle ist die Spalte Event wieder eine Konstante und nicht dynamisch während der Installation berechenbar ist. Ich möchte aber in der VCR.NET Installation auch erlauben, dass der Windows Dienst nach der Installation nicht automatisch gestartet wird. Natürlich kann man auch hier wieder den Weg mit den bedingten Komponenten gehen, dann sind es aber schon vier Kopien von quasi identischem Code.

Ich bin daher hier einen etwas anderen Weg gegangen: in der Installationssequenz wird die StartServices Aktion nur ausgeführt, wenn der Anwender dies auch tatsächlich wünscht. So kann in den Komponenten zum Dienst immer ein Startwunsch geäußert werden, der dann aber eventuell einfach nicht umgesetzt wird. Würde die Installation mehrere Dienste beinhalten und würde man grundsätzlich nur entscheiden, ob alle Dienste entweder gestartet werden oder halt nicht, so ist diese Lösung sicher tragbar.

Allerdings ist das auch der Knackpunkt. Eine Installation mit mehreren Diensten und individuellen Auswahlmöglichkeiten beider Optionen erzeugt eine ganze Menge Copy & Paste in der Installationsbeschreibung – egal, ob mit WiX erstellt oder anderweitig. Das wäre für mich dann schon der Punkt, an dem man über eine Custom Action nachdenken sollte. Im Nachhinein frage ich mich nur, nach welchen Kriterien wirklich entschieden wurde, ob eine Spalte einer Windows Installer Tabelle statisch oder dynamisch ist. Oft ist klar, dass potentiell mehrsprachige Spalten wie Anzeigename oder Beschreibung berechenbar sind. Die ganze Infrastruktur des Windows Installers wäre aber vermutlich viel mächtiger und vielseitiger, wenn alle Spalten dynamisch verfügbar wären. Aber da ist wohl nicht mehr dran zu rütteln…

So long

Jochen

“Der Router ist kaputt – das sehe ich aber sofort”

Von | |
Kommentare deaktiviert für “Der Router ist kaputt – das sehe ich aber sofort”

Da es nun schon mal zum vierten Mal passiert ist und sowohl der Telekom-Support vor Ort als auch der 1&1 Support am Telefon an dieser Mär festhält, hier ein keiner Statusbericht zur Aufklärung. Ich verwende einen älteren Fritz!Box WLAN 7170 Router als Anschluss ans DSL. Ab und an (lobenswerter Weise selten, aber immerhin viermal in 2,5 Jahren) ist die Leitung auch mal extern gestört – letztens ein Kabelbruch im Verteiler.

Wenn dieser Fall eintritt und man führt einen Kaltstart (Netzstecker ziehen) des Routers durch, so passiert folgendes (Interpretation, AVM fragen geht leider nicht mehr, da das Modell nicht mehr unterstützt wird): die Box versucht den Aufbau der DSL Verbindung (WLAN LED an, Power LED blinkt im Doppeltakt). Je nach Zustand der DSL Verbindung macht sie das eine Weile, wobei zwischendurch auch mal ein Trennung und Re-Synchronisation probiert wird. Irgendwann ist wohl eine interne Schwelle von Fehlversuchen überschritten und der Router führt einen vollständigen Neustart durch. Danach geht das von vorne los.

Aber irgendwann wird es ganz spannend, dann ist der Router es wohl leid: nach einem Neustart wird KEIN neuer Versuch mehr unternommen, die DSL Verbindung herzustellen. WAN LED ist an, Power LED blinkt langsam UND ALLE ANDEREN LEDs blinken auch. Wenn aber alle LEDs blinken muss der Router (zumindest im oben aufgeführten Personenkreis) wohl kaputt sein – Diskussionen und Hinweise haben sich im Praxistest als völlig sinnlos erwiesen.

Tatsächlich muss man in diesem Zustand NACH der Reparatur der DSL Verbindung einen Kaltstart durchführen, da der Router dies von sich aus nicht macht. Interessant am Rande: irgendwie hat selbst das den Telekom Techniker vor Ort nicht wirklich überzeugt – obwohl der Router wieder einwandfrei arbeitete.

Also bitte liebe Supportmitarbeiter: wenn bei einem 7170 Router alles blinkt heißt das noch lange nicht, dass der Router kaputt ist. Vielleicht ist es ja wirklich ausnahmsweise 🙂 mal die Leitung! Leider gilt das umgekehrt aber nicht: wenn der Router mal tatsächlich kaputt ist, dann blinken evtl. auch alle LEDs. Aber immerhin ist es einen Versuch wert, die Leitung zu prüfen, oder?

Jochen

Yield und Reacquire in MSBuild Tasks

Von | |
Kommentare deaktiviert für Yield und Reacquire in MSBuild Tasks

So richtig klar war mir die Verwendung dieser Methoden in einer eigenen MSBuild Task nicht – bis es dann knallte. Daher hier eine Anwendung mit meiner vermuteten Interpretation des Verhaltens, vielleicht hilft das ja dem einen oder anderen beim Verständnis und der Entwicklung eigener MSBuild Tasks.

Die Aufgabenstellung war eigentlich recht einfach und vermutlich auch nicht unüblich: eine größere Anzahl (800+) von Projekten soll mit MSBuild so schnell wie möglich auf einer eventuell potenten Maschine gebaut werden – im Test ein Dual-Xeon mit insgesamt 8 Kernen auf 2 Prozessoren mit zusätzlichem Hyper Threading, also insgesamt 16 logischen Kernen sowie einer SSD. Erst einmal sieht das aus wie eine triviale Aufgabe für die MSBuild Task und der BuildInParallel Option. Natürlich kann es nicht so einfach sein, da die Projekte untereinander abhängig sind und in einer bestimmten Reihenfolge gebaut werden müssen. Also schnell mal eine Visual Studio (2013) Solution On-The-Fly gemacht und die mit der MSBuild Task gebaut. Das geht im Prinzip auch aber leider nicht in dem konkreten Fall: neben C++ und C# Projekten gibt es besondere Projektarten, die Visual Studio und MSBuild nicht kennen. Theoretisch kann man das natürlich in die Infrastruktur von MSBuild einbringen (à la WiX et al), aber ich bin hier einen anderen Weg gegangen.

Ich verzichte auf die Details und erzähle nur das, worum es hier geht: die Projekte werden mit ihren Abhängigkeiten untereinander als MSBuild Items angelegt und einer MSBuild Dispatcher Task übergeben. Diese startet auf jedem MSBuild Knoten einen Build Vorgang mit einer speziellen Worker Task. Jede dieser Worker Tasks fordert bei dem Dispatcher ein Projekt zum Bauen an, baut dieses und teilt dem Dispatcher dann das Ergebnis mit. Der Dispatcher sorgt dafür, dass die Projekte in der korrekten Reihenfolge gebaut werden. Die Kommunikation zwischen Worker und Dispatcher ist über einen trivialen In-Process WCF Dienst und ein Named Pipe Binding geregelt.

Das funktionierte auch eine Weile und dann stand alles still – ein Deadlock. Was war passiert? Wenn ein Worker den Dispatcher nach einem neuen Projekt zur Bearbeitung fragt kann es sein, dass gerade keines zur Verfügung steht, weil abhängige Projekte noch in Berechnung sind. In diesem Fall wartet der WCF Aufruf des Workers, bis alle abhängigen Projekte abgearbeitet sind. Aus Sicht von MSBuild ist der MSBuild Node des Workers aber damit in Benutzung und kann nicht für andere Zwecke genutzt werden. In der besonderen Situation ergab es sich, dass alle Nodes bis auf einen (also hier: 15) auf eine besonders zentrale Abhängigkeit warteten, die von dem verbleibenden Node gebaut wurde. Dummerweise erforderte dieses Bearbeiten aber, dass MSBuild eine weiteren Node zur Abarbeitung anfordern musste und damit stand alles.

Hier kommt nun Yield ins Spiel: unmittelbar vor dem WCF Aufruf des Workers an den Dispatcher teilt die Dispatcher Task MSBuild via BuildEngine3.Yield() mit, dass der Node nun anderweitig beschäftigt ist. MSBuild kann dem Node nun andere Aufgaben zuordnen und der Deadlock ist weg. Wichtig ist, dass nach dem WCF Aufruf und sicher VOR dem nächsten MSBuild Zugriff des Workers ein BuildEngine3.Reacquire() erfolgt. Sollte auf dem Node zu diesem Zeitpunkt noch eine andere Aufgabe aktiv sein, so wird MSBuild den Reaquire Aufruf blockieren (das ist eine Vermutung, die aber durchaus Sinn macht), bis die andere Aufgabe abgeschlossen ist. Danach widmet sich der MSBuild Node wieder gänzlich unserer Worker Task.

Viel Spaß beim Coden

Jochen