Sequenzieren benutzerdefinierter Aktionen

Benutzerdefinierte Aktionen werden in Sequenztabellen auf die gleiche Weise wie Standardaktionen geplant.

So planen Sie eine benutzerdefinierte Aktion in einer Sequenztabelle

  1. Geben Sie den Namen der benutzerdefinierten Aktion (primärer Schlüssel der CustomAction)-Tabellein die Spalte Aktion der Tabelle Sequence ein.
  2. Geben Sie die Sequenz der benutzerdefinierten Aktion relativ zu den anderen Aktionen in der Tabelle in die Spalte Sequenz der Tabelle Sequence ein. Weitere Informationen zu Sequenztabellen finden Sie unter Verwenden einer Sequenztabelle.
  3. Um die Aktion bedingt zu überspringen, geben Sie einen bedingten Ausdruck in die Spalte Bedingung der Tabelle Sequence ein. Das Installationsprogramm überspringt diese Aktion, wenn der Ausdruck falseausgewertet wird.

Wie bei Standardaktionen werden benutzerdefinierte Aktionen, die in InstallUISequence oder AdminUISequence geplant sind, nur ausgeführt, wenn die interne Benutzeroberfläche auf die vollständige Ebene festgelegt ist. Die Benutzeroberflächenebene wird mithilfe der MsiSetInternalUI-Funktion festgelegt.

Standardmäßige und benutzerdefinierte Aktionen, die in den Tabellen InstallExecuteSequence, AdminExecuteSequenceoder AdvtExecuteSequence geplant sind, nehmen keine Systemänderungen vor. Stattdessen werden vom Installationsprogramm Ausführungsdatensätze in einem Skript für die nachfolgende Ausführung während des Installationsdiensts in die Warteschlange gestellt. Wenn kein Installationsdienst verfügbar ist, werden die in diesen Tabellen geplanten Aktionen im gleichen Kontext wie die Benutzeroberflächensequenz ausgeführt.

Wenn der Installationsserver nicht registriert ist, werden die benutzerdefinierten Aktionen auf der Clientseite ausgeführt. Wenn der Server registriert ist und den vollständigen Benutzeroberflächenmodus verwendet, werden die benutzerdefinierten Aktionen auf der Serverseite ausgeführt.

Bei Verwendung der vollständigen Benutzeroberfläche mit dem Server werden die anfänglichen Aktionen vor der InstallValidate-Aktion auf dem Client ausgeführt, um eine vollständige Interaktion zu ermöglichen. Die Ausführung wird dann auf den Server umgeschaltet, der diese Aktionen wiederholt und die Skriptausführungsaktionen ausgeführt. Darauf folgt eine Rückgabe an den Client für die endgültigen Aktionen.

Beachten Sie, dass die REMOVE-Eigenschaft möglicherweise erst nach der InstallValidate-Aktion gleich ALL ist, wenn ein Produkt entfernt wird, indem es sein oberstes Feature auf absent (fehlend) setzt. Dies bedeutet, dass alle benutzerdefinierten Aktionen, die von REMOVE=ALL abhängig sind, nach der InstallValidate-Aktion sequenziert werden müssen. Eine benutzerdefinierte Aktion kann REMOVE überprüfen, um zu ermitteln, ob ein Produkt vollständig deinstalliert wurde.

Benutzerdefinierte Aktionen, die auf eine installierte Datei als Quelle verweisen, z. B. Benutzerdefinierter Aktionstyp 17 (DLL), Benutzerdefinierter Aktionstyp 18 (EXE), Benutzerdefinierter Aktionstyp 21 (JScript) und benutzerdefinierter Aktionstyp 22 (VBScript), müssen die folgenden Sequenzierungseinschränkungen einhalten.

  • Die benutzerdefinierte Aktion muss nach der Aktion CostFinalize sequenziert werden, damit der Pfad zur Datei, auf die verwiesen wird, aufgelöst werden kann.
  • Wenn die Quelldatei noch nicht auf dem Computer installiert ist, müssen verzögerte (skriptbasierte) benutzerdefinierte Aktionen nach installFiles sequenziert werden.
  • Wenn die Quelldatei noch nicht auf dem Computer installiert ist, müssen nach der InstallInitialize-Aktion nicht standardmäßige benutzerdefinierte Aktionen sequenziert werden.

Die folgenden Sequenzierungseinschränkungen gelten für benutzerdefinierte Aktionen, die ein Paket Windows Installer ändern oder aktualisieren.