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
Neulich bei einem Regsvr32.exe /silent Aufruf einer DLL Datei wurde folgende Fehlermeldung (obwohl der Silent-Paramenter verwendet wurde) ausgegeben:
The module xyz.dll failed to load.
Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line systrace.exe tool for more detail.
Eigentlich dürfte dieses Fenster nicht erscheinen, da der /silent parameter verwendet wurde.
Man sollte sich auch nicht durch die side-by-side configuration in die Irre führen lassen und einfach den guten alten Dependency Walker verwenden.
Der Depency Walker zeigt die fehlenden Komponenten an, welche vor der Registration auf dem Rechner vorhanden sein müssen.
Es geht auch Stück für Stück mit dem Event-Log, der in einem Error Eintrag die benötigte DLL anzeigt.
Kurz gesagt, neue Meldung, altes Problem
Dieser Post geht auf den Test Expert ein, welcher mit einer Wise Package Studio Quality Assurance Erweiterung oder mit der Wise Package Studio Suite Edition zur Verfügung steht.
Im Wise Test Expert existiert unter ‘Application Verification Tests’ ein Class IDs Test Case. Mit diesem Test Case lassen sich Klassen, also Registry Einträge unter HKCRCLSID automatisch Testen, ohne die Applikation starten und alle Funktionen sowie Unterfunktionen testen zu müssen.
Dieser Test Case unterliegt der ClassID Tabelle der ausgewählten Applikation und verwendet die CoCreateInstance Funktion um die Funktionalität der Klasse zu verifizieren. Natürlich erhofft man sich bei der Verwendung des Wise Test Expert ein Erfolgs-Resultat von 100%. Die Praxis zeigt uns jedoch, dass bei den Class IDs Tests ein Resultat von 20% schon eine voll funktionierende Applikation ausweissen kann.
Der Grund für diesen Beitrag besteht darin offen zu legen, warum im Test Expert bei den Class IDs Test ein Resultat von 20% schon gut genug sein kann.
Ich habe über die Jahre alle möglichen Resulate aus dem Test Experten analysiert und eine Liste erstellt, worin zu ersehen ist, bei welchen ‘Error Numbers’ eine Installation auf Fehler zu überprüfen ist und bei welchen Nummern die Klasse als funktionsfähig einzustufen ist.
| Error Number | Error Description | Real Error |
| 0x80040154 | Class not registered | maybe |
| 0x80004002 | No such interface supported | no |
| 0x80080005 | Server execution failed | no |
| 0x80004005 | Unspecified error | no |
| 0x80040111 | cannot supply requested class | no |
| 0x8007007E | The specified module could not be found | yes |
| 0x8000FFFF | Catastrophic failure | no |
| 0x80040112 | Class is not licensed for use | no |
Die Liste zeigt auf, es gibt verschiedene Gründe, warum ein Klassen-Test fehlschlagen kann.
Bei folgenden Fehler-Nummern kann die betroffene Klasse korrigiert werden:
Class not registered: Der Test kann nochmals durchgeführt werden, nach dem die betroffene Klassen-Datei (.DLL oder .OCX) mit dem Programm regsvr32.exe registriert wurde. Sollte nach einem erneuten Test die Klasse erfolgreich gestet werden können, so kann die fehlende Klasse in die Installation eingebaut werden.
The specified module could not be found: Verwenden Sie den Dependency Walker von Microsoft um die fehlende(n) Datei(en) in die Installation einzubauen.
Bei den restlichen Fehlermeldungen liegt fast sicher kein Problem vor, oder dieser lässt sich aus Sicht eines System-Administrator nur sehr selten verbessern.
Zusammenfassend muss ich festhalten, dass ein Klassen-Test mit der CoCreateInstance Funktion keine optimale Lösung ist, um eine verlässliche Aussage treffen zu können, ob eine Klasse wirklich funktioniert. Die Test-Resulate liefern viele Error Codes zurück, obwohl die Applikation funktionieren wird. Schlussendlich hat ein Software Hersteller verschiedene Möglichkeiten eine Klasse für seine Applikation zu inizialisieren.
Die Windows Installer Technologie bietet bereits von Haus aus diverse Directory Properties um auf “Special Folders” Werte zugreifen zu können.
Leider gibt es jedoch immer wieder der Fall, dass man auf zusätzliche, nicht durch den Windows Installer bereits zu Verfügung gestellte Werte zugreifen muss.
Mit folgendem VBScript kann man sich diese Werte allerdings schaffen. In unserem folgenden Beispiel ermitteln wir den “Common Documents” Folder.
Folgendes Skript fügen wir als “CALL VBScript From Embedded Code” Aktion im Immediate Bereich ein:
Const CSIDL_COMMON_DOCUMENTS = &h2e
Set objShell = CreateObject(“Shell.Application”)
Session.Property(“ONTX_COMMON_DOCUMENTS”) = objShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path
Set objShell = nothing
Zu beachten ist, das wir diese Aktion vor “CostFinalize” durchführen müssen.
Um den Wert auch für Komponenten verwenden zu können, sollte man noch einen Eintrag in der Directory Tabelle erfassen:
Danach kann man das Property/Directory wie üblich verwenden.
Eine Liste aller Special Folders befindet sich im Anhang dieses Artikels.
Nach der Migration des Wise Package Studio Servers auf die Version 8.0 ist es leider auch nötig die Netzwerk Client Installationen zu aktualisieren.
Je nach Packaging Umgebung kann dies jedoch enormen Aufwand bedeuten.
Mit folgendem Trick kann man sich diesen Aufwand allerdings sparen:
– Installiere den Network Client der 8.0 Version auf einer sauberen VM/Client
– Exportiere danach den “Wise Solutions” Registry key. In diesem Key sind die neuen Lizenzinformation drin. Ohne diese lässt sich WPS 8.0 nicht starten.
– Erstelle ein neues WiseScript und füge mittels “Edit Registry” Aktion diese Keys hinzu
– Als 2 Aktion füge eine “Run Executable” Aktion hinzu, und zeige dort auf die “PackageStudio8.exe” Executable auf dem Wise Package Studio Share.
– Kompiliere ein neues Executable und lege dies im Wise Package Studio Programmverzeichnis als “PackageStudio7.exe” ab
Nun wird bei alten Netzwerk Client Installationen die PackageStudio7.exe gestartet, welche die benötigten Registrierungsschlüssel für das Wise Package Studio 8 ins Benutzerprofil schreibt und danach die aktuelle PackageStudio8.exe startet.
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.
Jedem der sich schon länger mit Wise Package Studio befasst wird sicher schon die WisePathReplacement Tabelle aufgefallen sein.
Was genau steckt hinter dieser nützlichen “Custom” Wise Tabelle?
Dank Ihr gibt es die Möglichkeit in der Registry Werte zu verändern, die der Windows Installer nicht direkt als Variablen unterstützt. Davon betroffen in der Repaketierung sind Verzeichnisse, die ohne Backslash enden und Pfade im 8.3 Format. Viele ersetzen diese einfach mit Windows Installer Verzeichnis-Variablen bzw. File-Keys, dies kann aber zu Problemen bei div. Applikationen führen. Dank der WisePathReplacement Tabelle und den dazugehörigen Custom Actions werden solche Information in der Registry Tabelle erkannt und mit dynamischen Werten modifiziert.
Die Erkennung der Werte in der Registry Tabelle geschieht nur während eines Setup-Capture Prozesses. Wenn Werte nachträglich ersetzt werden müssen, dann können Sie die WisePathReplacement Tabelle verwenden, müssen jedoch sicherstellen dass die benötigten Einträge in der CustomAction und InstallExecuteSequence Tabelle vorhanden sind.
Folgende Werte können Sie mit Hilfe der WisePathReplacement Tabelle modifizieren:
– Directory Properties ohne abschliessenden Backslash.
– Dynamische 8.3 Pfade
Die Konfiguration gestaltet sich sehr einfach (automatisch beim Setup-Capture):
In der WisePathReplacement Tabelle trägt man die Primär-Key‘s des gewünschten Registry Wertes ein und legt die gewünschte Funktion fest:
1 = Kein Backslash am Ende.
2 = Pfad in 8.3 Format konvertieren.
3 = Beide Funktionen vereint (1+2).
Das ganze führen wir natürlich mit einem praktischen Beispiel vor.
Wir haben ein Paket mit folgenden Registry Key‘s:
Die Registry-Key Namen sollten jeweils selbsterklärend sein. Um den gewünschten Effekt zu erzeugen ergänzen wir die WisePathReplacement Tabelle:
Das Resultat nach der Installation ist wie folgt:
Während einem Setup Capture Prozess werden die benötigten Custom Actions automatisch eingebaut. Bei einer manuellen Anpassung müssen die benötigten Custom Action nachgetragen werden:
