Hier finden wir nun den zweiten und abschliessenden Teil mit Informationen über die Directory Tabelle und das Handling mit Directorybezeichnern im Windows Installer.
Wer den ersten Teil nicht gelesen hat, dem empfehle ich folgenden Link zur Durchsicht: Inside Directories in Windows Installer – Teil 1
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“))
MsiDoAction() 
