Konfliktmanagement in der Softwarepaketierung

Was bisher geschah…

Hallo miteinander
Schon bald lange ist’s her seit meinen letzten Beiträgen. Und ich muss zugeben, dass ich in der letzten Zeit etwas zu beschäftigt war und leider nicht die Zeit für regelmässige Beiträge fand. Jetzt bin ich aber wieder da, mit alter Frische und bereit der Welt viele positive Überraschungen zu offenbaren. Aber lassen wir die Katze nicht gleich im ersten Blog nach dieser Pause aus dem Sack.

MSI Logfile Analyzer

Den meisten wird der Windows Installer Verbose Log Analyzer aus dem Microsoft SDK (WiLogUtl.exe) bekannt sein. Schon öfters habe ich positive Statements und Lob für dieses Produkt gelesen, konnte mich aber selbst mit diesem Tool nicht wirklich anfreunden. Auch mein Kollege und Tischnachbar scheint hier eine ähnliche Ansicht zu vertreten und hat die Gelegenheit sogleich beim Schopf gepackt und einen Logfile Analyzer programmiert, der seinen Namen würdig ist.

Ich habe die Ehre, den ersten public Release dieses Tools hier vorstellen zu dürfen. Probiert es aus und ich bin mir sicher, auch Ihr werdet begeistert sein….

Inside Directories in Windows Installer - Teil 2/2

Hier finden wir nun den zweiten und abschliessenden Teil mit Informationen über die Directory Tabelle und das Handling mit Directorybezeichnern im Windows Installer.
Wer den ersten Teil nicht gelesen hat, dem empfehle ich folgenden Link zur Durchsicht: Inside Directories in Windows Installer - Teil 1

 

Inside Directories in Windows Installer - Teil 1/2

Inspiriert von Rob Menschings historischer Blogserie  ”Deciphering the MSI Directory table” und von Programmiertätigkeiten, wo ich auch auf Directoryinformationen angewiesen war, erlauben folgende Ausführungen einen kurzen Einblick in die Directory Tabelle und das Handling mit Directorybezeichnern in zwei Teilen.  

Wise Package Studio und Windows Vista

Eigentlich sollte es die letzte Version von Wise Package Studio (7.0 SP2 ) nicht nur erlauben, dass man damit Pakete für Windows Vista erstellen kann. Grundsätzlich müsste die Suite auch selbst auf diesem Betriebssystem laufen. Folgende Probleme ergeben sich aber beim Betrieb unter Windows Vista:

Berücksichtigung der Pending Files Rename queue (PFR) im Installationsprozess

Die “PendingFiles”-Problematik war am Rande schon einmal Thema dieses Blogs. Nichts desto trotz möchte ich mit diesem Artikel eine weitere Möglichkeit aufzeigen, wie Probleme im Zusammenhang mit dem Update von “in use” Daten vermieden werden können.

 

command prompt mit drag & drop auch unter Vista!

Wer hat sich nicht auch schon darüber geärgert, dass unter Windows Vista kein drag & drop mehr auf das Konsolenfenster cmd.exe möglich ist? Eine Alternative ist die Verwendung von Shift + rechte Maustaste „Copy as Path“ beim Übertragen von komplexen Pfadnamen vom Explorer in das Konsolenfenster. Es gibt aber auch praktischere Alternativen und command prompt Emulatoren.

Probleme bei der Datei- und Registrierungsvirtualisierung in Windows Vista

Programme, die mit Standard User Rechten ausgeführt werden – und das sind bei eingeschalteter UAC alle, die nicht mit einem Manifest mit einer erhöhten Ausführungsebene markiert sind – werden unter Windows Vista besonders behandelt. Werden diese Programme mit dem Standard User Token ausgeführt, werden alle Zugriffe auf das Verzeichnis %PROGRAMFILES%,  %WINDIR%,  und %WINDIR%\System32 sowie auf die Registry unter HKLM\Software umgeleitet.

Welche Bedeutung hat der Windows Vista Restart Manager im Deployment?

Windows Vista versprach uns mit dem Restart Manager in Kooperation mit Windows Installer eine neue Technologie mit deren Hilfe sich die Reboots am Computer hätten minimieren lassen sollen. Ein grosses Bedürfnis, welches wir in der Softwareverteilung schon lange haben. Leider vergass Microsoft (oder ich habs nicht wirklich gesehen und gehört) beim Rühren in der Werbetrommel, darauf hinzuweisen, dass der Restart Manager nur etwas für User ist, welche interaktiv ein Setup aufrufen. Dass dies in der Softwareverteilung in den allerwenigsten aller Fälle so ist, vergass man schlicht.

Zwar wird von Microsoft ausgewiesen, dass ein sessionübergreifender Shutdown von Applikationen nicht unterstützt wird…

 
http://msdn2.microsoft.com 

Beeinflussen der Sortierreihenfolge für die DeInstallation fremder Produktfamilien beim MajorUpgrade

Bei Windows Installer Setups wird innerhalb des MajorUpgrades mittels der Action RemoveExistingProducts eine DeInstallation allfälliger Vorprodukte initiiert. Die DeInstallation erfolgt dabei während des Installationsprozesses als eingebettete Installation innerhalb der gleichen Installationsinstanz. Um eine DeInstallation auszulösen muss der entsprechende UpgradeCode in der Upgrade Tabelle eingetragen sein und diesem eine Property über ActionProperty zugewiesen werden, welche über SecureCustomProperties als Public Property bekannt gemacht wurde. Die meisten Authoringtools verfügen über einfache Verfahren, diesen Upgrade zu implementieren. Schwieriger wird es, wenn man eine bestimmte DeInstallationsreihenfolge vorgeben möchte, vor allem wenn es sich um produktlinienfremde Applikationen handelt, die vor der eigenen Produktlinie entfernt werden sollen. Denn Windows Installer ermittelt die zu deinstallierenden Produkte über die Action FindRelatedProducts und sortiert die ermittelten ProductCodes nach eigenem Schlüssel. Die Sortierung setzt sich folgendermassen zusammen:

Vorgehen, wenn TTF-Dateien bei einem Major Upgrade nicht neu geschrieben werden

Vielleicht haben Sie auch schon die Situation beobachtet, dass zum Teil True-Type Fontdateien (möglicherweise auch noch andere Arten von Dateien) bei einem Major Upgrade nicht neu kopiert werden. Ein Blick ins Web verrät zwar, dass offenbar mehr Leute als zunächst angenommen davon betroffen sind, meistens enden aber solche Forumsbeiträge entweder unbeantwortet oder mit einem fassungslosen „kann ich auch nicht verstehen“.

Beispiele:
http://community.macrovision.com/archive/…
http://groups.google.ch/group/microsoft.public.windows.msi…
http://forums.altiris.com/messageview.aspx?…

Der Grund für dieses Verhalten ist darauf zurückzuführen, dass Windows Installer im Gegensatz zu den meisten Authoringtools andere Algorithmen zur Bestimmung einer Dateiversion anwendet!
Wird in einem Major Upgrade die Action RemoveExistingProducts in der InstallExecuteSequence Tabelle gemäss Empfehlung von Microsoft ( http://msdn2.microsoft.com/… ) nach InstallValidate eingeordnet, so kann sich bei augenscheinlich unversionierten TTF-Dateien folgendes Verhalten zeigen: CostFinalize weist beim MajorUpgrade folgende Zeile aus:

Repaketier kein Windows Installer Setup

Für den Softwareverteilungsprozess geltende „Best practice“ Ansätze und Richtlinien im Handling von MSI-Dateien.

Kaum haben wir uns an das Repackaging gewohnt, werden wir nun vor allem durch die Verbreitung von Hersteller-Setups basierend auf Windows Installer Technologie vermehrt gezwungen, andere Mechanismen zur Paketerstellung zu verwenden. Dass es sich dabei nicht zwingend um unangenehme Paketiermechanismen handelt, soll hier aufgezeigt werden. Daneben werden wir auch verstehen lernen, warum es so immens wichtig ist, dass Herstellersetups, die die Windows Installer Technologie verwenden möglichst nicht aufgezeichnet werden sollten.