We are happy to announce our newest service addition for our customers.
The Ontrex SPA Software Packaging Channel
As from now we are excited to publish free youtube tutorials/casts in several packaging disciplines/tools like AdminStudio, APP-V & Wix.
We will also cover any topics about the recent EOL announcement of Wise Package Studio including but not limited to “Migration to AdminStudio” casts.
Regards,
SPA Team
Als ich kürzlich den Artikel Test your conditions von Heath Stewart gelesen habe, wusste ich sogleich, dass es nun an der Zeit ist die letzten technischen Details über die REMOVE Kondition preis zu geben.
Wie die REMOVE Kondition optimal eingesetzt wird entscheidet die Feature Struktur eines Produktes. Eine einfache Aussage wie REMOVE~=”ALL” zu verwenden, ist keine gute Idee, da es Situationen gibt, wo diese Kondition nicht greift.
Fact ist, dass die REMOVE Kondition im Falle einer Deinstallation verwendet werden kann.
Fact ist, dass bei einer repaketierten Applikation, im Generellen die Kondition REMOVE verwendet werden kann.
Der Ausdruck REMOVE~=”ALL” hat sich über ein Jahrzehnt stark verbreitet. Der Wert ALL bedeutet, dass alle Features eines Produktes deinstalliert werden, sprich die Installation wird komplett deinstalliert. Dies ist die allgemeine Annahme in der Software Paketierung.
REMOVE~=”ALL” wird jedoch nicht in allen Situationen funktionieren, wie es Heath Stewart schon angedeutet hat. Es gibt eine Situation, den Wartungsmodus um es genau zu benennen, wo diese Kondition nicht greift. Betroffen davon sind besonders Software-Entwickler, da dessen Deinstallationen öfters mit dem Wartungsmodus durchgeführt werden und von diesem Problem betroffen sind.
Ein Produkt kann über folgende vier Wege deinstalliert werden.
Deinstallation mittels Befehlszeile (msiexec.exe -x <product code> /qb) wie gewöhnlich ein Produkt automatisch deinstalliert wird:
MSI (s) (28:5C): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL
Deinstallation über Control Panel > Add or Remove Programs, wie es ein Endanwender eine Deinstallation durchführen wird:
MSI (s) (28:F8): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL
Deinstallation über den Wartungsmodus einer MSI Installation (Modify, Repair oder Remove Option im Setup Wizard)
MSI (s) (28:5C): Command Line:
MSI (c) (28:1C): Switching to server: REMOVE=Complete
MSI (s) (28:10): PROPERTY CHANGE: Adding REMOVE property. Its value is ‘Complete’.
MSI (s) (28:10): PROPERTY CHANGE: Modifying REMOVE property. Its current value is ‘Complete’. Its new value: ‘ALL’.
Property(S): REMOVE = ALL
Deinstallation über die Windows Installer API
MSI (s) (28:EC): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL
Es wird nun ersichtlich, das eine Deinstallation über den Wartungsmodus anders abläuft als die restlichen Deinstallationswege. Beim Wartungsmodus steht es von beginn an nicht fest, welche Windows Installer Aktion der Anwender ausüben wird. Daher kann die REMOVE Property nicht von Beginn an definiert werden.
MSI (s) (28:5C): Command Line:
In der REMOVE Property stehen alle Feature Namen des aktuell installierten Produktes (Features werden mit ; getrennt falls mehrere installiert sein sollten).
MSI (c) (28:1C): Switching to server: REMOVE=Complete
MSI (s) (28:10): PROPERTY CHANGE: Adding REMOVE property. Its value is ‘Complete’.
Anhand der Windows Installer SDK steht fest, das der Remove Control Event das Argument ALL dem REMOVE Property der Installations-Session weiter geben muss, damit das gesamte Produkt deinstalliert wird.
MSI (s) (28:10): PROPERTY CHANGE: Modifying REMOVE property. Its current value is ‘Complete’. Its new value: ‘ALL’.
Property(S): REMOVE = ALL
Entscheidend ist, die Action InstallValidate erkennt den Remove Control Event Eingriff und ändert den Wert in der REMOVE Property auf ALL.
Dies bedeutet: Wird ein Produkt über den Wartungsmodus deinstalliert, so werden Konditionen mit dem Argument REMOVE~=”ALL” erst nach der InstallValidate Aktion funktionieren.
Sollte früher eine Aktion diese Kondition verwenden, so wird diese nicht ausgeführt.
Oft begegnet man in der Software Paketierung dem Problem, dass man eine unversionierte Datei ersetzen will, dies aber nicht immer auf Anhieb gelingt.
Der Grund ist meist schnell gefunden, die Datei wurde mittlerweile modifiziert oder aus anderen Gründen stimmt das Create/Modified Datum nicht mehr überein. Deshalb verhindern auch die Default File Versioning Rules das erfolgreiche Ersetzen der Datei.
Die Windows Installer Technologie bietet aber hierfür eine elegante Lösungsmöglichkeit an, welche leider oft in Vergessenheit gerät.
Companion Files, zu Deutsch: Begleit-Dateien, bezeichnet man Dateien in der Installation, bei denen man eine andere Datei als “Entscheidungsträger” definiert.
Beispiel:
Für userdata.usr (unversioniert) konfiguriert man “MyVersioned.dll” (versioniert) als “Entscheidungsträger”. Sofern MyVersioned.dll installiert wird (Beispiel: Höhere Version als bestehende MyVersioned.dll), wird auch userdata.usr installiert.
Wise Package Studio kann dies wie folgt realisiert werden:
Den Mechanismus in Aktion sieht man entsprechend in der Logfile:
File: C:Program FilesMyProjectuserdata.usr; Overwrite; Won’t patch; Existing file is of an equal version (Checked using version of companion: C:Program FilesMyProjectMyVersioned.dll)
Weiterführende Information gibt es natürlich wie immer im Windows Installer SDK:
http://msdn.microsoft.com/en-us/library/aa367997%28VS.85%29.aspx
Die Windows Installer 2709 Fehlermeldung ist eine Benachrichtigung, die bei einer Update Installation erscheinen kann. Wird eine betroffene Installation auf einer Clean Machine installiert, so sieht alles gut aus, keine Fehlermeldung erscheint. Sollte die gleiche Installation als Update Installation durchgeführt werden, so erscheint die 2709 Fehlermeldung. Interessant dabei ist, das der Test auf einer Clean Machine eigentlich das gleiche Problem haben sollte, das Problem aber aus internen Abläufen der Windows Installer Session automatisch korrigiert wird.
Das Problem kann unter anderem durch ein Setup-Capture mit Wise Package Studio entstehen, wenn Dateien mit Merge Modulen ersetzt werden. Wie in diesem Beispiel wurde die Datei comdlg32.ocx durch ein Merge Module von Microsoft ersetzt. Dieser Vorgang löscht jedoch nicht die Verweise der bereits erstellten Componenten in der FeatureComponents Tabelle.
Komponenten die während einem Setup-Capture mit einem Merge-Module ersetzt wurden, bleiben in der FeatureComponents Tabelle zurück
Das etwas mit diesen Komponenten nicht stimmt, wird in der Tabellenansicht des Windows Installer Editors ersichtlich. Werden diese Einträge übersehen, so wird auf diesen Misstand während der Validierung darauf hingewiesen:
Not a valid foreign key; Table: FeatureComponents, Column: Component_, Key(s): Complete.comdlg32.ocx ice03.html FeatureComponents Component_ Complete comdlg32.ocx
Evaluation: ICE03
Diese Einträge sind aus der FeatureComponents Tabelle zu löschen. Es kann jedoch vorkommen, das die Validierung aus unbekannten Gründen bei dieser Überprüfung fehlschlägt und keine Probleme angezeigt werden. Bei einem anschliessenden Testdurchlauf der Installation wird keine Fehlermeldung erscheinen, da die Windows Installer Session diese fehlerhaften Einträge überspringt.
Doing action: InstallValidate
Feature: Complete; Installed: Absent; Request: Local; Action: Local
Component: CreateFolder; Installed: Absent; Request: Local; Action: Local
Component: registry44; Installed: Absent; Request: Local; Action: Local
Component: findmsm.exe; Installed: Absent; Request: Local; Action: Local
Während der InstallValidate Aktion werden die betroffenen Komponenten ausgewählt, die fehlerhaften Einträge werden einfach übergangen.
Soweit scheint alles zu funktionieren, bis zu dem Tag, an dem mit der gleichen Installation ein Update durchgeführt wird. Bei einer Update Installation wird zusätzlich die MigrateFeatureStates Aktion durchgeführt. Diese überprüft die Stati der bereits Installierten Features und vererbt die Feature States bei der Update Installation (Die Vererbung von Feature Stati kann mit der Upgrade Tabelle deaktiviert werden). Die Aktion MigrateFeatureStates übergeht die fehlerhaften Einträge in der FeatureComponents Tabelle jedoch nicht und wird mit der Fehlermeldung 2709 die Installation abbrechen.
DEBUG: Error 2709: The specified Component name (‘comdlg32.ocx’) not found in Component Table.
In diesem Fall sind in der Installation die fehlerhaften Einträge in der FeatureComponents Tabelle zu beheben. Wir empfehlen diese Überprüfung in die Best-Practices von Software-Paketierungs Guidelines aufzunehmen, um diesem Problem zuvor zukommen.
Nach den Regeln der alten Windows Installer Schule wird gelernt, das beim Einsatz von Custom Actions Verzeichnisse der Directory Tabelle erst nach der CostFinalize Aktion zur Verfügung stehen.
Demnach sollen Custom Actions, die mit Verzeichnis-Verweise arbeiten, erst nach der CostFinalize Aktion ausgeführt werden.
Die CostFinalize Aktion wird alle Verzeichnisse für die Windows Installer Session bereitstellen.
MSI (s) (F8:E8): Doing action: CostFinalize
MSI (s) (F8:E8): PROPERTY CHANGE: Adding TARGETDIR property. Its value is ‘C:’.
Interessanterweise kann bei der AppSearch Aktion mit Verzeichnissen wie WindowsFolder und ProgramFilesFolder gearbeitet werden obwohl diese vor der CostFinalize Aktion ausgeführt wird. Dementsprechend gibt es Verzeichnisse die schon vor der CostFinalize Aktion verwendet werden können.
Bei der Analyse einer Log-Datei wird ersichtlich, das vor der INSTALL Session, also noch bevor überhaupt eine Aktion ausgeübt werden kann, alle SpecialFolders (Magic Folders) aufgelöst werden und danach sofort zur Verfügung stehen.
Mit dem APICall SHGetFolderPath werden SpecialFolders aufgelöst.
MSI (s) (F8:E8): SHELL32::SHGetFolderPath returned: C:Documents and SettingsAdministratorApplication Data
Bei der Analyse der Log-Datei, sieht man jedoch den WindowsFolder, SystemFolder und den ProgramFilesFolder nicht aufgelistet. Diese Verzeichnisse stehen wie die restlichen SpecialFolders bei Beginn der INSTALL Session zur Verfügung.
Somit lässt sich aussagen, das SpecialFolders von Beginn der Installation verwendet werden können und Verzeichnisse, welche die Installation selber erstellt, nach der CostFinalize Aktion.
Mit dieser Erkenntnis können viele Custom Actions, welche mit SpecialFolders arbeiten, schon vor der CostFinalize Aktion ausgeführt werden.
In dem heutigen Post geht es in der Windows Installer Technologie um die Situation, dass eine INI Datei während einer Reparatur nicht aktuallisiert werden soll.
Das Standard-Verhalten bei einer Reparatur ist wiefolgt: Der Inhalt einer INI-Datei wird mit den Werten aus der INIFile Tabelle verglichen und bei einer Differenz mit den ursprünglichen Werten überschrieben.
Sollte ein Endbenutzer Änderungen an einer INI-Datei vorgenommen haben, so gehen diese bei einer Reparatur des Produktes verloren.
Gemäss der Windows Installer SDK kann über die Aktions-Spalte mit dem Wert 1 festgelegt werden, dass ein Eintrag nur überschrieben wird, falls dieser nicht vorhanden sein sollte. In vielen Fällen wird die Änderung der Aktion die Situation entschärfen, da die Vorgabe auch bei einer Reparatur angewendet wird.
Mit der Action-Spalte lassen sich zusätzliche Modifikations-Optionen für INI-Dateien einstellen
Betrachtet man die Situation genauer, so kann es sein, dass ein Endanwender Werte aus der INI-Datei löscht. Diese werden bei einer Reparatur wieder hergestellt und verwirft damit die Konfiguration des Endanwenders. Es gibt keine Modifikations-Option die diese Situation berücksichtigt. Eine Möglichkeit bietet die Verwendung einer Kondition in der InstallExecuteSequence Tablle bei der WriteIniValues Aktion. Die WriteIniValues Aktion schreibt die Werte einer INI-Datei anhand der Instruktionen der INIFile Tabelle. Mit der Kondition NOT REINSTALL kann die Aktion bei einer Reparatur ausgelassen werden. Damit geht die Reparaturfunktion aller INI-Dateien verloren, was an dieser Stelle zu erwähnen ist.
Bei der Reparatur kann die Modifikation von INI-Dateien ausgeschaltet werden
Sollten die beschriebenen Möglichkeiten keine Alternative zur Situation sein, so stehen weitere Möglichkeiten über Benutzerdefinierte Aktionen (Custom Actions) zur Verfügung. Eine einfache Möglichkeit ohne viel Aufwand mit Scripting-Sprachen zu verbringen bietet der Wise Script Editor. Mit der Funktion Editet INI File kann eine INI-Datei erstellt werden. Die Custom Action ist mit der Kondition NOT Installed zu versehen, dann wird die Datei nur erstellt jedoch nicht geändert bei einer Reparatur.
Mit dem WiseScript Editor lassen sich einfach INI-Dateien erstellen.
Die Anzahl von Programmupdates, die auf Microsoft Windows Installer Patch-Dateien (.MSP) aufbauen, nehmen kontinuierlich zu. Dabei können Patch-Dateien auf unterschiedliche Wege ein Produkt aktualisieren.
Die folgenden Details zu einer Administrativen-Installation (Netzwerk-Installation) sind ein Bestandteil aus unserer Windows Installer Schulung ‘Schwarzgurtpaketierung’, die wir ab nächstem Jahr in unser Kursprogram aufgenommen und kürzlich als Power-Workshop im grösseren Kundenumfeld präsentiert haben.
Eine Möglichkeit der Patch-Integration ist eine Admin-Installation durchzuführen und diese mit einer Patch-Datei zu aktualisieren. Die aktualisierte Windows Installer Installation kann sowohl auf neuen Rechnern installiert werden, sowie bestehende Installationen über einen Reparatur-Zyklus auf den neuen Stand bringen.
In den meisten Fällen muss von der Original-Installation eine Admin-Installation durchgeführt werden (msiexec.exe -a datei.msi). Obwohl dies eine ‘High-Level’ Aktion ist, also eine grundlegende Windows Installer Funktion, ist dies keine Garantie dafür, dass der Software-Hersteller diese vollumfänglich unterstützt.
Ein Seiteneffekt kann die Feature Level 0 Problematik sein. Diese führt dazu, dass nicht alle Dateien extrahiert werden, da die Condition Tabelle bei einer Admin-Installation nicht abgearbeitet werden.
Es ist also vor einer Admin-Installation darauf zu achten, ob in der Feature-Tabelle ein Feature mit dem Level 0 existiert. Sollte dieses Feature-Level während einer normalen Installation geändert werden, so ist vor der Admin-Installation der Wert des Features zu erhöhen und nach der Admin-Installation wieder zurück zu stellen. Danach kann die Patch-Datei integriert werden.
Mit Hilfe der Condition Tabelle kann ein Software-Hersteller während der Installation ein Feature-Level anhand von Konditionen verändern. Dies geschieht jedoch nicht während einer Admin-Installation, was zu Dateiverlusten führen kann.
Weitere Informationen zu unseren Wise Kursen sind auf unserer Schulungsseite zu finden http://www.ontrex.ch.
Durch die Einführung des Dual-Token in Windows Vista müssen die Setup-Autoren bei der Erstellung von Custom Actions darauf achten, dass Aktionen, welche Änderungen an Per-Machine Ressoucen vornehmen, als In-Script (deferred) Aktionen unter dem System Kontext ausgeführt werden. Nur dadurch wird eine Aktion im Admin-Token durchgeführt.
Bei älteren Installationen kann es vorkommen, dass eine Aktion, welche mit Variablen (Properties) arbeitet, im Immediate Bereich der ExecuteSequence Tabellen ausgeführt wurden. Ab Vista werden diese zum Grösstenteil nicht mehr funktionieren, da diese nun im Standard LPU ausgeführt werden und dadurch zu wenig Rechte besitzen. Im Grunde genommen ist dies auch der richtige Ansatz, denn spätestens bei einem Self-Repair einer Installation mit Standard Benutzerrechten unter Windows XP hätte diese Aktionen das gleiche Problem wie in einem Dual-Token Umfeld.
Davon betroffen ist auch das Borland BDE Merge Module. Wenn diese Merge Module unter Windows Vista oder Windows 7 verwendet wird, so bleibt die Installation mit der Meldung ‘Unable to merge new configuration. Use BDE Amdinistrator to merge your new configuration.’ stehen. Das Fenster muss manuell geschlossen werden.
Die Frage stellt sich nun, was muss getan werden, um dieses Problem zu lösen. Die Antwort jedoch fällt nicht so einfach aus.
Wenn man die Log-Datei der Installation ansieht
Doing action: BDEConfig.E966F0CB_76B3_11D3_945B_00C04FB1760A
dann wird dieses Fenster durch die BDEConfig Aktion verursacht. Die Aktion wird nach InstallFinalize im Immediate, sprich im Standard LPU ausgeführt, und dafür ist die Aktion nicht vorgesehen. Leider wurde der Support für die BDE Technologie schon seit einem Jahrzehnt eingestellt. Mittlerweile kann man sogar das Merge Module nicht mehr herunterladen, geschweige denn eine aktuelle, verbesserte Version von Borland beziehen.
Damit die Installation unter Vista ohne die Dialog-Box durchläuft, muss die Kondition in der InstallExecuteSequence Tabelle abgeändert werden. Dieser Eingriff sollte direkt im Merge Module vorgenommen werden (ModuleInstallExecuteSequence Tabelle).
Mit dem Zusatz ‘AND VersionNT < 600′ wird die Aktion nur noch unter Betriebssystemen vor Windows Vista durchgeführt.
Durch diesen Eingriff wird die BDEMERGE.INI nicht mehr abgearbeitet. Das lässt sich leider nicht verhindern. Diese Funktion muss nachgebaut, sollten Änderungen in der idapi32.cfg vorgenommen werden.
Eine Möglichkeit bietet das Wise Installation System 9, es beinhaltet Funktionen wie Add BDE Alias (Da der BDE Support eingestellt wurde, sind die BDE Funktionen in den aktuellen Versionen des Wise Installation System nicht mehr vorhanden).
Eine weitere Möglichkeit bietet die idapinst.dll. Diese DLL beinhaltet die Funktionen wie MergeCfg oder AddAlias. Die Dokumentation über diese Funktionen sind heute so gut wie unauffindbar. Mann spürt hier ganz klar, dass der Support von BDE schon lange eingestellt wurde.
Wenn nun alle Stricke reissen sollten, dann wäre eine weitere Möglichkeit das betroffene Programm zum Beispiel mit SVS oder APP-V zu virtualisieren, da dadurch eine eigenständige idapi32.cfg verwendet werden kann.
Stefan Hotan
A member of the Ontrex SPA Team
Vor allem im Corporate IT Umfeld ist es eine bekannte Gewohnheit gewisse „spezielle“ Verzeichnisse (Special Folders) via Group Policy auf Netzlaufwerke auszulagern (Folder Redirection). Einige Beispiele hierfür sind:
| MSI Property | Bezeichnung | Standardeinstellung englisches Windows XP |
Beispiel Redirection Pfad |
| AppDataFolder | Application Data | C:Documents and SettingsUSERNAMEApplication Data | \myserveruserhomes$USERNAMEApplication Data |
| PersonalFolder | My Documents | C:Documents and SettingsUSERNAMEMy Documents | \myserveruserhomes$USERNAMEMy Documents |
Diese werden dann je nach verwendeter Architektur mittels Offline-Folders Mechanismus mit dem Client synchronisiert.
Der Windows Installer mag diese Gegebenheit vom Design her nicht, insbesondere wenn diese Lokationen nicht zur Verfügung stehen.
Der Windows Installer initiiert nämlich während der CostFinalize Aktion die gesamte Directory Tabelle und überprüft dabei die Verfügbarkeit sämtlicher dieser Verzeichnisse, d.h ob sie existieren, beschreibar sind etc.
Ein praxisbezogenes Beispiel: Ein Notebook Benutzer ruft im Hotel zum ersten mal den VPN Client auf, welches ein Self-Repair verursacht damit die Benutzerkonfiguration per-User installiert wird.
Während dieses Self-Healings (gilt auch für ActiveSetup oder Repair) wird diese Überprüfung der „umgeleiteten“ Lokationen in einem Fehler enden, da er nicht auf das Netzlaufwerk zugreifen kann und somit diese “special folders” überprüfen kann. Folgende Fehlermeldung erscheint:
Das Programm lässt sich dann überhaupt nicht mehr über die advertised Shortcuts aufstarten.
Lösung
Falls die „Special Folders“ nicht dringend benötigt werden, also z.B keine Dateien in diesen Ordnern platziert werden müssen, sollte man diese aus der Directory Table löschen.
Der Windows Installer wird dann beim Self-Healing/Active Setup nicht mehr versuchen diese zu überprüfen.
Fabio Di Lorenzo
Member of the Ontrex SPA Team
