Im ersten Teil haben wir gesehen, wie die Verzeichnisstruktur innerhalb der Directory Tabelle aufgebaut ist. In diesem Teil werden wir auf spezielle Charakter in der DefaultDir Spalte eingehen und kurz die Handhabung von Verzeichnisbezeichnern innerhalb von anderen Windows Installer Tabellen oder innerhalb von Scripts besprechen.

Spezielle Charakter in der DefaultDir Spalte
Der Punkt „.“

Mit einem Punkt in der Spalte DefaultDir wird kein neues Verzeichnis definiert, sondern die Operation mit der Gleichsetzung auf Directory_Parent abgeschlossen.  In dieser Spalte wird also keine Operation angewendet, daher spricht man hier auch von einem NoopFolder (stammend aus  "no operation", bzw. "no-op"). Ein NoopFolder ist mit Directory_Parent identisch und die Angabe kann beispielsweise dann Sinn machen, wenn nur für das Quell- oder Zielverzeichnis eine Verzeichnisänderung erreicht werden soll (siehe nächster Absatz) und jeweils für das andere Verzeichnis nicht. Zum Teil werden NoopFolder-Einträge  auch verwendet, weil es sich bei dem Verzeichnis um einen Top Level Bezeichner handelt, welcher automatisch aufgelöst (Standardverzeichnis) oder anderweitig deklariert (public Property) wird. Oft werden aber auch nur „Redirections“ von  bestehenden Verzeichnissen auf einen neuen Key damit bewerkstelligt, weil  leere Einträge in der DefaultDir Spalte nicht erlaubt wären.

Der Doppelpunkt „:“

Mit dem Doppelpunkt werden Quell- und Zielverzeichnisse voneinander getrennt, wenn diese unterschiedlich sind. Enthält die Zeichenkette keinen Doppelpunkt, so sind Quell- und Zielverzeichnis gleich und entsprechen der in DefaultDir angegebenen Zeichenkette. Wird hingegen ein Doppelpunkt verwendet „:“, dann zielt der linke Teil vom Doppelpunkt auf das Zielverzeichnis und der rechte Teil auf das Quellverzeichnis. Somit wird auch obiges Beispiel besser verständlich, wo das Quellverzeichnis von „ZweitesDir“ einen anderen Wert ausgibt, als das entsprechende Zielverzeichnis. Es ist nämlich mit dem NoopFolder identisch, da nach dem Doppelpunkt „:“ in der Deklaration ein Punkt angewendet wurde. Im Beispiel unten werden dagegen  echte unterschiedliche Verzeichnisse definiert:

Das Pipe Zeichen „|“

Mit dem Pipe Zeichen trennt man short names (8.3) von langen Dateipfadnamen. Verwendet man short names, dann dürfen diese auch  keine Leerzeichen enthalten. Zudem sollten sie nicht den Standardregeln vom Dateisystem abgeleitet sein (PROGRA~1, MICROS~1,MYDIRE~2), sondern auf anderer Logik beruhen. Als short name deklarierte Pfade werden beispielsweise verwendet, wenn die Property SHORTFILENAMES gesetzt ist. Bei der Verwendung des Pipe Zeichens befindet sich links  davon der short name, rechts davon der lange Name.

Verwendung von Verzeichnissen in anderen Tabellen

Alle Verzeichnisbezeichner aus der Directory Tabelle können gleich verwendet werden wie jede andere Property auch. Wenn also in einer Condition eine Prüfung auf ein Verzeichnisbezeichner erfolgt, so unterscheidet sich die Verwendung nicht von der Verwendung von Windows Installer Properties. Auch Verweise in Registrykeys mittels der Brackets „[ProgramFilesFolder]“, werden durch Windows Installer anstandslos aufgelöst und mit dem richtigen Pfad ersetzt.

Der Formatted Datentyp

Directorybezeichner entsprechen dem Formatted  Datentyp. Diese Properties können innerhalb der Klammernpaare „[]“ ausgewertet werden. Wenn Windows Installer eine Zeichenfolge in der Form [property] oder [directory] ermittelt, wird der Ausdruck mit dem Inhalt der Property/des Verzeichnisses ersetzt. Verzeichnisse werden folgendermassen aufgelöst:

[directory]
Der Directorybezeichner wird vollständig aufgelöst. Beispielsweise auf „C:\Program Files\MeinDir\“.

[#filekey] 
Das komplette Verzeichnis inkl. Dateinamen der Datei, welche dem Filekey aus der File Tabelle entspricht, wird aufgelöst.  Beispielsweise auf "C:\Program Files\MyDir\Datei.TXT"
Achtung: Die Auflösung erfolgt nur, wenn CostInitialize, (FileCost) und CostFinalize durch Windows Installer ausgeführt wurden. Sollte vorher auf [#filekey] zugegriffen werden, wird eine leere Zeichenfolge  "" aufgelöst.

Interessant: Sollte die Komponente als „run from Source“ markiert sein, liefert [#filekey] den Sourcepfad der Datei, ansonsten wird das Zielverzeichnis aufgelöst. Wenn die Komponente einen Aktionsstatus auf „absent“ enthält, bestimmt der Installationsstatus den Inhalt von [#filekey]. Sollte dieser auch absent oder NULL sein, so wird [#filekey] eine leere Zeichenfolge zugewiesen. Mit anderen Worten, sollte die Komponente durch die Installation nicht installiert werden (beispielsweise aufgrund dessen, weil der Level  Eintrags des Features > INSTALLLEVEL Property ist  - feature will be not installed) und fehlt diese Komponente lokal auf dem System so ergibt [#filekey] einen Leerstring "".

[$componentkey]
Diese Verwendung weist Windows Installer an, das komplette Verzeichnis der angegebenen Komponente aufzulösen. Auch hier erfolgt eine Auflösung nur nach den entsprechenden Actions CostInitialize, (FileCost) und CostFinalize. Sollte die Komponente als „run from Source“ markiert sein, liefert [$componentkey] den Sourcepfad der Datei, ansonsten wird das Zielverzeichnis aufgelöst.
Die Auswertung bezieht sich auf den Aktionsstatus der angegebenen Komponente.  Steht dieser auf Local oder Source, wird entsprechend das Quell- oder Zielverzeichnis aufgelöst. Befindet sich die Zeichenfolge [$componentkey] in der Value Spalte der Registry Tabelle, wird zusätzlich der Anforderungsstatus überprüft.

[!filekey]
Windows Installer löst das komplette Verzeichnis inkl. Dateinamen eines Filekeys als short name auf. Diese Verwendung ist nur in der Value Spalte der Registry - und IniFile Tabelle gültig. Ausserhalb dieser Tabellen ersetzt Windows Installer diese Zeichenfolge mit der [#filekey] Repräsentation.

Folgende Beispiele verdeutlichen die Verwendung von [$component] und [#filekey]:
(die Stati beziehen sich auf die auszulesende Komponente, bzw. auf die dem filekey zugewiesenen Komponente)

Verwendung und Ermittlung von Verzeichnissen innerhalb von Programmen und Scripts

Bevor der eine oder andere schon an die Umsetzung einer rekursiven Funktion zum Ermitteln eines Zielverzeichnisses einer Komponente geht, möchte ich eine andere, weit einfachere Möglichkeit aufzeigen, um auf den kompletten Verzeichnisnamen in externen MSI Dateien mittels dem Windows Installer Automationsmodell zugreifen zu können. Über dass Session Objekt können mittels
Session.TargetPath oder Session.SourcePath (Achtung: oSession.DoAction("ResolveSource") zuerst ausführen)  Quell- oder Zielverzeichnisse von Directory-Bezeichnern ermittelt werden. Noch einfacher und globaler einsetzbar, geht es mit der Session.FormatRecord Methode, welche  einfach den Formatted Datentyp auswertet. Im unten dokumentierten Beispiel gehen wir bei den Vorbereitungen noch einen Schritt weiter, als im letzten Kapitel, indem wir neben den FileCosting Actions zusätzlich AppSearch ausführen. Dies hat den Vorteil, dass über  AppSearch  zu ermittelnde Verzeichnisse ebenfalls ausgewertet werden.

Hier ein einfaches Beispiel mittels dem Windows Installer Automationsmodell:

Dim sDir, oSession, oInstaller, oRecord
Set oInstaller = Wscript.CreateObject("WindowsInstaller.Installer")
Set oSession = oInstaller.OpenPackage("C:\meineMsi.MSI", 1)
oSession.DoAction("AppSearch")
oSession.DoAction("CostInitialize")
oSession.DoAction("CostFinalize
Set oRecord = oSession.Installer.CreateRecord(1)
oRecord.StringData(0)="[ProgramFilesFolder]"
msgbox( "FormatRecord: " & oSession.FormatRecord(oRecord))
msgbox( "TargetPath: " & oSession.TargetPath("ProgramFilesFolder"))

Viele, die schon einmal einen Blick in die Directory Tabelle geworfen haben, werden sich über deren Aufbau gewundert haben. Meistens scheut man es, Verzeichnisse zur Kontrolle  in Orca „per Hand“ aufzulösen und schaut daher lieber mal in den Editoren der Auringtools nach, wie ein entsprechendes Verzeichnis nun ausgeschrieben aussehen mag. Es gibt aber Situationen, wo wir uns über den Aufbau im Klaren sein müssen oder wo wir per Script den vollständigen Verzeichnisnamen benötigen. Für diese  Zwecke und für das allgemeine Verständnis sind nachfolgende Zeilen gedacht:

In einer Windows Installer Datenbank finden wir Verzeichnisangaben in der Directory Tabelle. Alle Verzeichnisreferenzen aller Komponenten verweisen auf  den Primary Key dieser Directory Tabelle und sind an sich Windows Installer Properties. Diese Tabelle wird schliesslich während des File Costing Prozesses durch Windows Installer ausgewertet.

Der Aufbau der Directory Tabelle

Die Directory Tabelle enthält drei Spalten,  Directory, Directory_Parent und DefaultDir. Die Spalte Directory ist zugleich der Primary Key der Tabelle, d.h auch, dass dieser einen eindeutigen und einmalig vorkommenden Namen enthalten muss. Man sieht es bereits am Namen der Spalte Directory an, dass diese Spalte der Primary Key der Tabelle ist, da die Namen der Tabelle (Directory) und der Spalte (Directory) identisch sind.  Bei Windows Installer Standard Tabellen, wo nur ein Primary Key vorkommt, wird oft in der Schlüsselspalte der selbe Name verwendet.
Eine Verzeichnisstruktur setzt sich aus dem Verweis auf einen Key in Directory_Parent und dem Unterverzeichnis (DefaultDir) zusammen. Das Auflösen der Directory_Parent erfolgt hierbei in mehreren Schritten maximal bis zu einem der Standardverzeichnisse, bis zu TARGETDIR  (bzw. SourceDir) oder bis zu einem als public Property deklarierten Directory, welches durch AppSearch, CustomAction Typ 35 oder 51, durch die Commandline  oder in der Property Tabelle definiert wurde.  Abgeschlossen wird jede Verzeichnisangabe schliesslich durch ein Backslash „\“ am Ende der Zeichenkette.

Beispiel:

Top Level Verzeichnisse

Als Top Level Verzeichnisse werden hier Verzeichnisse benannt, die nicht weiter durch die Standardmechanismen aufgelöst werden müssen, da sie selbst durch Windows Installer während der Installation bestimmt werden. Diese Verzeichnisse bilden die "Root", aber müssen sich aber nicht auf ein Root-Verzeichnis beschränken. Das Verzeichnis ProgramFilesFolder, welches auf "C:\Program Files" zeigen könnte, ist demnach beispielsweise ein Top Level Verzeichnis.

Die Auflösung der Top Level Verzeichnisse  erfolgt durch Windows Installer auf verschiedene Art und Weise. Standardverzeichnisse werden wie die komplette  Auswertung der Directory Tabelle auch innerhalb der Action CostFinalize aufgelöst. Diese werden dort aber durch die API Funktion SHGetFolderPath() ermittelt. Das Top Level Standardverzeichnis ProgramFilesFolder wird dabei beispielsweise mit der Zeichenkette “C:\Program Files\” gleichgesetzt und das LocalAppData Verzeichnis bekäme unter Windows Vista für eine Installation in meinem Kontext beispielsweise den Wert „C:\Users\oberlind\AppData\Local“.
In der Directory Tabelle verwendete public Properties werden hingegen durch die Action AppSearch, durch die Deklaration in der Property Tabelle, durch CustomActions Typ 35 oder 51, durch die Commandline oder durch das SetTargetPath() ControlEvent (bei full UI) deklariert. Für jedes  verwendete  Top Level Verzeichnis muss sich ein gültiger Eintrag in der Directory Tabelle befinden. Diese Deklaration wird aber während der Ausführung der MSI mit den „echten“ Werten überschrieben.

Beispiel mit Top Level Verzeichnissen TARGETDIR, ProgramFilesFolder und MYDATS:

Zielverzeichnisse nach dem FileCosting beim Installieren via
„msiexec.exe  /i msi.msi MYDATS=C:\ProgramDat\Root“:

Man beachte, dass MYDATS automatisch ein Backslash angehängt wurde. Hätte man im Beispiel auf ein Verzeichnis mit Leerzeichen verweisen wollen, bspl. MYDAT=C:\Program Files\ProgramDat\Root, so wäre die Angabe von Anführungszeichen in der Commandline erforderlich gewesen:MYDATS=“C:\Program Files\ProgramDat\Root“.

TARGETDIR, SourceDir und ROOTDRIVE

Das Top Level Verzeichnis TARGETDIR bestimmt das Rootverzeichnis der Installation. TARGETDIR muss sich in der Directory Tabelle befinden, ansonsten erhält man Fehlermeldungen wie diese: „Root directory property undefined“. Die Deklaration muss hierbei folgenden Aufbau haben:

Falls der Inhalt von TARGETDIR bei der Installation nicht definiert wurde (beispielsweise über die Commandline), wird die Property ROOTDRIVE aufgelöst, um den Pfad zu ermitteln. Sollte auch ROOTDRIVE weder in der Property Tabelle noch über die Commandline angegeben worden sein, setzt Windows Installer bei einer Administrativinstallation diese Property auf das erste verfügbare und beschreibbare Netzwerklaufwerk. Bei einer Installation wird diese Property hingegen auf das Laufwerk mit dem grössten verfügbaren Speicherplatz gesetzt. Das sind die Gründe, warum im Deployment die Verwendung auf ROOTDRIVE=C:\ in der Property Tabelle empfohlen ist. Nichtbeachten dieser Regel kann dazu führen, dass eine Installation auf dem einen PC auf das lokale Laufwerk C:\ erfolgt, bei einem benachbarten  Gerät hingegen auf Laufwerk D:\, wenn dort beispielsweise eine zweite Disk mit mehr Platz verfügbar ist.
Bei einer Administrativinstallation wird die Angabe von TARGETDIR in der Commandline empfohlen, da dadurch das Zielverzeichnis angegeben wird, wohin die Administrativinstallation erfolgen soll:

Msiexec.exe /a mymsi.msi TARGETDIR=H:\AdminP

Bei der Property SourceDir müssen keine expliziten Deklarationen in der Directory Tabelle erfolgen. SourceDir repräsentiert denn auch das Quellverzeichnis. Externe Cabinettdateien oder extern und unkomprimiert vorliegende Sourcedaten werden bei einer Installation oder Reparatur in diesem Verzeichnis gesucht. Auch CustomActions können aus diesem Verzeichnis ausgeführt werden oder auf dieses Verzeichnis über MsiGetProperty zugreifen. Die SourceDir Property wird über die Action ResolveSource, welche nach CostInitialize einzuordnen ist, initialisiert.

Tip: Möchten Sie alle Zugriffe bei einer Deinstallation auf das Installationsverzeichnis und allfällige SOURCELIST Verzeichnisse unterbinden, können Sie dies mit der Condition NOT REMOVE=“ALL“ bei ResolveSource in der InstallExecuteSequence Tabelle steuern.

Betrachtungen im Installationsprozess

Die Verzeichniseinträge werden während des Installationsprozesses in der Regel sowohl im Client-, als auch im Serverprozess ermittelt. Dabei werden die Verzeichniseinträge der Directory Tabelle während des File Costing Prozesses durch den DirectoryManager über das Installationsmodul des entsprechenden Prozesses ausgewertet.
Während dieser Phase werden die Directorybezeichner entsprechenden Properties zugewiesen. In einer Protokolldatei mit Verboseinformationen findet man daher nach der Ausführung von CostFinalize auch ein Dump dieser ermittelten Verzeichnisse.

Fortsetzung folgt...
Inside Directories in Windows Installer Teil 2/2