Wenn TTF-Files b. MajorUpgrade nicht neu geschrieben werden

Melchior Joined: 29 May 2006 Posts: 29

Vorgehen, wenn TTF-Dateien bei einem Major Upgrade nicht neu geschrieben werden.

Vielleicht haben Sie auch schon die Situation beobachtet, dass zum Teil True-Type Fontdateien (möglicherweise auch noch andere Arten von Dateien) bei einem Major Upgrade nicht neu kopiert werden. Ein Blick ins Web verrät zwar, dass offenbar mehr Leute als zunächst angenommen davon betroffen sind, meistens enden aber solche Forumsbeiträge entweder unbeantwortet oder mit einem fassungslosen „kann ich auch nicht verstehen“.

Beispiele:
http://community.macrovision.com/archive/index.php?t-116526.html
http://groups.google.ch/group/microsoft.public.windows.msi/browse_thread/thread/8c7aec5248a05aef/7091b11b33b73064?lnk=st&q=Disallowing+installation+of+component%3A++since+the+same+component+with+higher+versioned+keyfile+exists&rnum=12&hl=de#7091b11b33b73064
http://forums.altiris.com/messageview.aspx?catid=20&threadid=35319&enterthread=y

Der Grund für dieses Verhalten ist darauf zurückzuführen, dass Windows Installer im Gegensatz zu den meisten Authoringtools andere Algorithmen zur Bestimmung einer Dateiversion anwendet! Wird in einem Major Upgrade die Action RemoveExistingProducts in der InstallExecuteSequence Tabelle gemäss Empfehlung von Microsoft ( http://msdn.microsoft.com/library/en-us/msi/setup/removeexistingproducts_action.asp ) nach InstallValidate eingeordnet, so kann sich bei augenscheinlich unversionierten TTF-Dateien folgendes Verhalten zeigen: CostFinalize weist beim MajorUpgrade folgende Zeile aus:

Disallowing installation of component: {7DF425987-86EA-D534-B986-DCC5606AB567} since the same component with higher versioned keyfile exists

Dieses Verhalten kann bei TTF-Dateien ohne verändertem Zeitstempel, als auch bei TTF-Dateien mit neuerem Zeitstempel beobachtet werden, aber wie gesagt, bei Dateien ohne offensichtlicher Versionsinformation! Im Anschluss an CostFinalize würden solche Komponenten über RemoveExistingProducts entfernt (sofern nicht das Attribut msidbComponentAttributesPermanent verwendet wurde), aber durch den MajorUpgrade nicht wieder installiert, weil InstallValidate aufgrund der Ermittlung über das FileCosting angewiesen wurde, diese Komponenten wegen dem Vorfinden einer höheren Version nicht zu installieren.
InstallValidate weist daher auch eine Zeile der folgenden Art aus:
Component: MyComponent; Installed: Absent; Request: Local; Action: Null
Wird in einem solchen Szenario die Action RemoveExistingProducts entgegen der Microsoft Empfehlung vor das FileCosting, bzw. vor CostInitalize verschoben, so ändert sich das Verhalten zu unseren Gunsten. Jetzt funktioniert der MajorUpgrade korrekt, denn die Beurteilung, was durch den MajorUpgrade installiert werden soll erfolgt erst nach der vollständigen DeInstallation des Vorproduktes über RemoveExistingProducts.
Untersucht man dieses Verhalten genauer, kommt man zum Schluss, dass der Windows Installer bei der Überprüfung, ob eine Komponente auf dem System bereits in einer höheren Version vorhanden ist, zu einem anderen Ergebnis kommen muss, als, wenn wir im Explorer über das Kontextmenü/Properties auf den Versionstab schauen (Achtung: unter Vista wird die Version von TTF-Dateien hingegen angezeigt). Windows Installer ermittelt aber insbesondere andere Versionsinformationen, als unsere Authoringtools (Wise PackageStudio, InstallShield WinInstall und vielleicht auch noch andere), was diesen Effekt erst richtig zur Geltung kommen lässt. Denn all diese Authoringtools generieren beim Implementieren solcher TTF-Dateien (Snapshot oder direkt in den Editoren) in der Version Spalte der File Tabelle keinen Eintrag, obwohl Windows Installer darin eine Version erkennt. Es kann also durchaus gesagt werden, dass aus Sicht des Windows Installers diese Reaktion absolut in Ordnung ist.

Hintergründe zu CostFinalize
CostFinalize ermittelt die Dateiversion der physischen Datei einer im Paket referenzierten Komponente in dem entsprechenden Pfad und vergleicht diese mit dem Inhalt der Version Spalte innerhalb der File Tabelle. Wird bei einer TTF-Datei nun eine Version aus der physischen Datei gelesen, in der Version Spalte des MajorUpgrades ist hingegen keine Version angegeben, so entscheidet sich Windows Installer, diese Komponente entsprechend zu markieren, dass diese nicht erneut zu installieren sei. Die Action RemoveExistingProducts nach InstallValidate sieht hingegen keinen Anlass, diese Datei nicht zu entfernen. Unter diesem Kontext ist dieses Verhalten nun auch verständlich.

Anderes Verhalten bei normalen Dateien
Handelt es sich im vorliegenden Fall um eine „normale“ Datei mit „normalen“ Versionsinformationen (ocx, dll, exe, etc.) und wir bilden dort ein ähnliches Szenario ab, so erkennen wir im Falle, dass es sich um eine gleiche Komponente mit unterschiedlicher ComponentId handelt, dass Windows Installer gleich reagiert, wie oben beschrieben.
Ist hingegen die ComponentId identisch, so reagiert RemoveExistingProduct anders: Zwar wird CostFinalize nachwievor feststellen, dass eine Komponente mit neuer Version vorliegt, RemoveExistingProducts wird diese aber belassen und nun würde die gepackte ComponentId mit dem neuen ProduktCode registriert. Warum wir hier ein unterschiedliches Verhalten feststellen, ist mir ein Rätsel. Bei TTF-Dateien haben wir unabhängig der ComponentId immer das selbe Verhalten.

In welchen Fällen stellen wir ein unerwartetes Verhalten fest?
Wer die vorherigen Kapitel aufmerksam durchgelesen hat, kann diese Frage bestimmt beantworten:

Wenn eine Komponente eine TrueType-Datei als KeyFile hat, welche Versionsinformationen beinhaltet (nicht mit Explorer von W2K oder XP überprüfen!) und im MajorUpgrade keine gleich oder höherwertige Versionsinformation in der File Spalte der entsprechenden Komponente abgelegt ist und RemoveExistingProducts gem. Microsoft Empfehlung nach InstallValidate eingeordnet ist. (das sind auch alle drei anderen publizierten Orte: nach InstallInitialize, zwischen InstallExecute und InstallFinalize und nach InstallFinalize, da sich diese Orte auch nach dem FileCosting befinden)
Oder wenn eine in der Vorversion und im MajorUpgrade verwendete gleiche, aber versionierte „normale“ Datei (exe, dll, ocx, etc) mit unterschiedlicher ComponentId im MajorUpgrade und mit einer kleineren Version in der Version Spalte der File Tabelle markiert ist und RemoveExistingProducts gem. Microsoft Empfehlung nach InstallValidate eingeordnet ist.

Einfacher ausgedrückt sollten wir vorsichtig sein, wenn wir True-Type Dateien verwenden oder wenn wir bei bestimmten Komponenten einen Downgrade der als KeyFile deklarierten Dateien vornehmen.

Was lernen wir daraus? Wie reagieren wir auf dieses Verhalten?
Als Setupentwickler arbeiten wir nach Best Practice von Microsoft und verwenden nach Möglichkeit für gleiche Komponenten auch gleiche CopmponentIds. Tragen Sie auch für TTF-Dateien die entsprechende Dateiversion in die Version Spalte der File Tabelle ein und verhüten Sie einen Downgrade bei Komponenten. Werden diese Regeln befolgt, so kann mit ruhigem Gewissen die Empfehlung, dass RemoveExistingProducts nach InstallValidate eingeordnet sein soll umgesetzt werden.
http://msdn.microsoft.com/library/en-us/msi/setup/removeexistingproducts_action.asp

In einer Firmenumgebung und im Deployment, wo Sie Pakete für betrieblichen Einsatz repaketieren oder customizen, sollten Sie die Action RemoveExistingProducts VOR CostInitialize verschieben, insbesondere wenn Sie repaketierte Setups mit den bekannten Authoringtools (Wise, macrovision Flexnet, WinInstall) erstellen, welche die Versionsinformationen von TTF-Dateien nicht auslesen oder wenn Sie in Ihrer Umgebung auf einen Abgleich der jeweiligen ComponentIds aller im Einsatz befindlichen Pakete verzichten.

Dominik Oberlin

Piccolo Joined: 21 Oct 2006 Posts: 4

Guter Artikel!
Ich möchte nur nebenbei erwähnen, dass es durchaus Authoringtools gibt, die die Versionsnummer aus True Type-Fonts lesen.
Der AKInstallerMSI z. B.

Gruß
Cybot