Zusammenfassung: Beim Erstellen einer benutzerdefinierten Aktion in InstallShield Professional - Windows Installer Edition hat man die Auswahl zwischen mehren Einstellungen zur In-Script-Ausführung:
Dieser Artikel erklärt, was die aufgeführten Optionen bedeuten und wie damit festgelegt wird, in welcher Installationsphase eine benutzerdefinierte Aktion ausgeführt wird. Der Artikel hilft, die benutzerdefinierte Aktion an der richtigen Stelle in die Benutzeroberflächen- oder Ausführungssequenz einzufügen, um Fehlermeldungen wie diese zu vermeiden: "Skript-Eintrag kann nicht geschrieben werden. Die Transaktion ist nicht gestartet." ("Cannot write script record. Transaction not started.")
ENGLISCH:
English version of this article
RUSSISCH:
Перевод на русский язык доступен по ссылке:
http://www.installsite.ru/go/installationphases.htm
Dieser Artikel verwendet weitgehend die deutschen Fachbegriffe entsprechend der Übersetzung in InstallShield Professional - Windows Installer Edition Version 2.03 GERMAN. Wo in Einzelfällen davon abgewichen wurde, finden sich entsprechende Hinweise im Text. Daneben sind meist auch die englischen Begriffe in Klammern angegeben.
In der Benutzeroberflächen-Sequenz können nur benutzerdefinierte Aktionen mit sofortiger Ausführung verwendet werden. Dies gilt sowohl für die Sequenztabelle als auch für Aktionen, die mit DoAction als Ereignis eines Steuerelements aufgerufen werden.
Die Standardaktion ExecuteAction startet die Ausführungssequenz als Unterprozedur.
Wenn die Ausführungssequenz beendet ist, kehrt der Installer zur Benutzeroberflächen-Sequenz zurück und führt etwaige Aktionen aus, die nach ExecuteAction angegeben sind. Normalerweise befinden sich nach ExecuteAction keine weiteren Einträge in der Sequenztabelle, aber man kann dort benutzerdefinierte Aktionen einfügen, etwa um eine andere MSI-Installation zu starten.
Zum Schluss wird der Dialog SetupCompleteSuccess angezeigt, der durch die Sequenznummer -1 gekennzeichnet ist.
Der Teil der Ausführungssequenz zwischen InstallInitialize und InstallFinalize wird in zwei Phasen abgearbeitet: Zunächst geht der Installer alle Einträge (Standardaktionen und benutzerdefinierte Aktionen) durch und notiert sie in einem Installationsskript. Danach arbeitet er das Skript ab und führt die Kommandos tatsächlich aus. In diesem zweiten Durchgang wird der Zielcomputer modifiziert, d.h. Dateien werden kopiert, Registrierungseinträge werden geschrieben usw.
Wegen dieser zwei Phasen könnte es so aussehen, als würde der Installer die Ausführungssequenz zweimal durchlaufen: einmal beim Erstellen des Installationsskriptes und ein zweites Mal beim Ausführen des Skripts. Allerdings entspricht dieser Eindruck nicht ganz den Tatsachen.
Neben der Erzeugung und Abarbeitung des Installationsskriptes gibt es noch zwei spezielle Phasen: Commit und Rollback. Diese werden weiter unten im Text erklärt.
Während der Installer das Installationsskript erstellt, werden nur Aktionen mit sofortiger Ausführung gestartet. Alle anderen Aktionen (Standardaktionen wie InstallFiles und benutzerdefinierte Aktionen mit verzögerter Ausführung) werden nur im Skript notiert.
Alle Eigenschaftswerte (Properties) werden im Skript abgelegt und können nicht mehr geändert werden bis die Skriptausführung abgeschlossen ist.
Wenn Aktionen mit Bedingungen versehen sind, dann werden diese in der Skripterzeugungsphase ausgewertet.
Wenn das Installationsskript aufgebaut ist (d.h. beim Erreichen der Standardaktion InstallFinalize) beginnt der Installer mit der Abarbeitung des Skripts. Auf Computern mit Windows NT bzw. 2000 wird dazu ein gesonderter Prozess gestartet. Die gesamte Skriptausführung erfolgt "innerhalb" der InstallFinalize Aktion.
Während dieser Phase werden benutzerdefinierte Aktionen mit verzögerter Ausführung aufgerufen, zusammen mit all den Standardaktionen. Sie werden in der Reihenfolge ausgeführt, in der sie im Skript während der Erzeugungsphase abgelegt wurden; allerdings nur, wenn ihre Bedingung zum Zeitpunkt der Skripterzeugung erfüllt war.
Da diese Phase in einem separaten Prozess abläuft, können verzögerte benutzerdefinierte Aktionen nicht direkt auf Eigenschaftswerte zugreifen, und sie können keine Eigenschaftswerte setzen.
Während der Installer das Installationsskript abarbeitet baut er gleichzeitig ein Rollback-Skript auf. Für jede Standardaktion im Installationsskript wird ein entsprechender Befehl zum Rollback-Skript hinzugefügt. Änderungen, die durch eine benutzerdefinierte Aktion am Zielsystem vorgenommen werden, kann der Installer nicht automatisch zurücknehmen. Stattdessen werden die entsprechenden benutzerdefinierten Rollback-Aktionen im Rollback-Skript eingetragen.
Außerdem werden Sicherungskopien aller Dateien, die der Installer überschreibt, in einem temporären Verzeichnis angelegt.
Rollback-Aktionen werden in der Reihenfolge zum Rollback-Skript hinzugefügt, in der sie im Installationsskript angetroffen werden; allerdings nur, wenn ihre Bedingung zum Zeitpunkt der Erzeugung des Installationsskriptes erfüllt war.
Wenn die Installation vom Anwender abgebrochen wird oder während der Skriptausführung wegen eines Fehlers beendet werden muss, wird das Rollback-Skript ausgeführt, um das Zielsystem wieder in den ursprünglichen Zustand zurück zu versetzen. Dabei werden auch die benutzerdefinierten Rollback-Aktionen ausgeführt.
Das Rollback-Skript wird von unten nach oben abgearbeitet, d.h. die letzten Aktionen werden zuerst zurückgenommen.
Wenn das Installationsskript jedoch erfolgreich ohne Störung durchlaufen wurde, werden das Rollback-Skript und die Backup-Dateien gelöscht. Dann werden die benutzerdefinierten Commit-Aktionen ausgeführt.
Der Zielcomputer kann auch so eingestellt sein, dass Rollback deaktiviert ist. In diesem Fall wird kein Rollback-Skript erzeugt und es werden keine Sicherungskopien der überschriebenen Dateien angelegt.
In InstallShield Professional - Windows Installer German Edition ist diese Option mit "Erzwungene Ausführung" übersetzt, passender wäre wohl "abschließende Ausführung".
Commit-Aktionen sind das Gegenteil von Rollback-Aktionen. Während der Abarbeitung des Installationsskripts werden sie zu einem Commit-Skript hinzugefügt, ganz ähnlich wie Rollback-Aktionen zum Rollback-Skript hinzugefügt werden.
Commit-Aktionen werden nur im Commit-Skript eingetragen, wenn ihre Bedingung zum Zeitpunkt der Erzeugung des Installationsskriptes erfüllt war.
Das Commit-Skript wird am Ende der InstallFinalize-Aktion abgearbeitet, nachdem das Installationsskript vollständig durchlaufen wurde, und nur wenn die Installation nicht abgebrochen wurde.
Commit-Aktionen dienen dazu, eventuelle Sicherungskopien zu löschen, die von einer benutzerdefinierten Aktion angelegt wurden.
Ein Beispiel für die Verwendung von verzögerten, Rollback und Commit AktionenStellen Sie sich vor, eine benutzerdefinierte Aktion würde eine bereits vorhandene Datei ändern. Diese Aktion sollte verzögert ausgeführt werden, damit diese Änderung zurückgenommen werden kann, falls die Installation abbricht. Deshalb legt die benutzerdefinierte Aktion zuerst eine Sicherungskopie der Datei an, bevor sie modifiziert wird. Die Rollback-Aktion löscht die geänderte Datei und ersetzt sie durch die Sicherungskopie. Danach löscht sie die Sicherungskopie. Die entsprechende Commit-Aktion löscht die Sicherungskopie der Datei, da sie nach dem erfolgreichen Abschluss der Installation ja nicht mehr benötigt wird. |
Wenn auf dem Zielcomputer Rollback deaktiviert wurde, wird auch kein Commit-Skript angelegt. Commit ist das Gegenstück zu Rollback. Wenn Rollback deaktiviert ist, sollte die benutzerdefinierte Aktion keine Sicherheitskopie der Datei anlegen. Daher werden in diesem Fall Commit-Aktionen ignoriert.
Dies ist eine spezielle Variante der verzögerten Ausführung. Auf Windows NT/2000 läuft Windows Installer als Betriebssystem-Dienst und hätte damit vollen Zugriff auf das System. Um Anwender daran zu hindern, unerlaubte Änderungen am System vorzunehmen, führt Windows Installer jedoch alle Aktionen mit den Zugriffsrechten des aktuell angemeldeten Benutzers aus ("Impersonation"). Wenn auf dem Zielcomputer die Installation mit erhöhten Rechten (Elevated Privileges) vom Systemadministrator zugelassen wurde, wird dieser Typ von benutzerdefinierten Aktionen mit Systemprivilegien ausgeführt. Anstelle von "Verzögerte Ausführung im Systemkontext" wird in der MSI-Dokumentation der Ausdruck "Verzögerte Ausführung ohne Benutzerverkörperung" ("Deferred Execution with no User Impersonation") verwendet.
Abgesehen von den erhöhten Zugriffsrechten ist dieser Aktionstyp identisch zu benutzerdefinierten Aktionen mit verzögerter Ausführung, die oben beschrieben wurden.
Falls die Installation mit erhöhten Rechten nicht freigegeben ist, werden auch diese Aktionen mit Benutzerrechten ausgeführt, ebenso wie die anderen Aktionen mit verzögerter Ausführung.
Stefan Krüger arbeitet als freiberuflicher Setup-Berater. Er bietet Unterstützung, kundenspezifische Programmierung und Seminare unabhängig von InstallShield Software Corporation an. Neben diesen Dienstleistungen beantwortet er auch Fragen in verschiedenen Newsgroups und Diskussionsforen und betreut die Internetseiten von InstallSite.de, wo Setup-Entwickler Informationen und Beispiele miteinander austauschen.
Wenn Sie Kommentare zu diesem Artikel haben oder ein Thema vorschlagen
möchten, das in einem zukünftigen Artikel behandelt werden sollte, senden Sie
bitte eine E-Mail an
. Artikel von Stefan Krüger, die in älteren Ausgaben
des InstallShield Newsletter veröffentlicht wurden, finden Sie unter der Adresse
http://www.installsite.org/isnews.htm (in Englisch).
 |
News | Discussions | Windows Installer | Related Tools | More Help | InstallScript | About InstallSite | Shop | Site Search |
 |
Neuigkeiten | Diskussionsgruppen | Windows Installer | MSI FAQ | Artikel | Shop | Suche |
Copyright © by InstallSite Stefan
Krueger. All rights reserved. Legal
information.
Impressum/Imprint
Datenschutzerklärung/Privacy Policy
By using this site you agree to the license
agreement. Webmaster contact.
