WisePathReplacement

Published on February 3, 2010 in TECH and Wise Package Studio by Fabio Di Lorenzo. 0 Comments

Jedem der sich schon länger mit Wise Package Studio befasst wird sicher schon die WisePathReplacement Tabelle aufgefallen sein.

Was genau steckt hinter dieser nützlichen “Custom” Wise Tabelle?

Dank Ihr gibt es die Möglichkeit in der Registry Werte zu verändern, die der Windows Installer nicht direkt als Variablen unterstützt. Davon betroffen in der Repaketierung sind Verzeichnisse, die ohne Backslash enden und Pfade im 8.3 Format. Viele ersetzen diese einfach mit Windows Installer Verzeichnis-Variablen bzw. File-Keys, dies kann aber zu Problemen bei div. Applikationen führen. Dank der WisePathReplacement Tabelle und den dazugehörigen Custom Actions werden solche Information in der Registry Tabelle erkannt und mit dynamischen Werten modifiziert.

Die Erkennung der Werte in der Registry Tabelle geschieht nur während eines Setup-Capture Prozesses. Wenn Werte nachträglich ersetzt werden müssen, dann können Sie die WisePathReplacement Tabelle verwenden, müssen jedoch sicherstellen dass die benötigten Einträge in der CustomAction und InstallExecuteSequence Tabelle vorhanden sind.

Folgende Werte können Sie mit Hilfe der WisePathReplacement Tabelle modifizieren:

- Directory Properties ohne abschliessenden Backslash.
- Dynamische 8.3 Pfade

Die Konfiguration gestaltet sich sehr einfach (automatisch beim Setup-Capture):

In der WisePathReplacement Tabelle trägt man die Primär-Key‘s des gewünschten Registry Wertes ein und legt die gewünschte Funktion fest:

1 = Kein Backslash am Ende.
2 = Pfad in 8.3 Format konvertieren.
3 = Beide Funktionen vereint (1+2).

Das ganze führen wir natürlich mit einem praktischen Beispiel vor.

Wir haben ein Paket mit folgenden Registry Key‘s:

wpr_registry

Die Registry-Key Namen sollten jeweils selbsterklärend sein. Um den gewünschten Effekt zu erzeugen ergänzen wir die WisePathReplacement Tabelle:

wpr_wpr

Das Resultat nach der Installation ist wie folgt:

wpr_results

Während einem Setup Capture Prozess werden  die benötigten Custom Actions automatisch eingebaut. Bei einer manuellen Anpassung müssen die benötigten Custom Action nachgetragen werden:

  1. Wechseln Sie im “Installation Expert” auf die “Resources Ansicht”
  2. Klicken Sie auf “Add” um eine neue Resource hinzuzufügen.
    Die benötigte DLL für die Custom Actions befindet sich im Wise Package Studio Programmverzeichnis unter folgendem Pfad:
    [WisePath]\Stub\WiseApi.dll
  3. Der Resource gibt man den Namen “Callwiseapi”.
  4. Im “Setup Editor” wechselt man nun auf die Tabellen Ansicht und springt zur CustomAction Tabelle.
    Erfassen Sie die folgenden Custom Actions wie ersichtlich:
    wpr_customaction
  5. Zum Schluss müssen noch die neu erfassten Custom Actions in der InstallExecuteSequence eingebaut werden. Fügen Sie folgende neue Zeilen hinzu:
    wpr_ies

Firefox Plugins Repaketieren

Published on January 29, 2010 in Application Best Practices by Stefan Hotan. 0 Comments

Die Plugins von Firefox zu repaketieren ist im Grunde einfach. Wissenswert ist, dass es zwei verschiedene Möglichkeiten gibt, um Plugins bereitzustellen.

Firefox Plugins

In diesem Beispiel sind die Plugins für den RealPlayer und Quicktime auf einem Rechner installiert.

Diese Plugins werden auf unterschiedliche Wege eingelesen. Das RealPlayer Plugin wird über die Registry eingelesen, dessen Weg viele Software Hersteller verwenden.

plugins2

Die Registry-Einträge für ein Firefox Plugin können über Local Machine Keys bereit gestellt werden.

Das Quicktime Plugin wird über Dateien bereitgestellt. Diese werden in die von Firefox vorgesehenen Ordner (Components und Plugins) abgelegt. Dieser Weg der Plugin Bereitstellung ist seltener anzutreffen.

plugins4

Im Ordner Components wird die XPT (XPCOM Type Library) Datei Abgelegt, im Ordner plugins werden die Plugins selber abgelegt.

Fazit:
Firefox Plugins sind einfach zu Installieren, da diese Per-Machine Ressourcen sind. Wenn Firefox Plugins repaketiert werden sollen, dann ist Firefox vor einem Snap-Shot zu installieren, da nicht alle Applikationsentwickler die Plugins ohne Firefox installieren.

Mehr über XPCOM kann in Wikipedia nachgeschlagen werden.
http://en.wikipedia.org/wiki/XPCOM

Neue Komponenten Attribute in Wise Package Studio 8.0

Published on January 26, 2010 in Windows Installer by Fabio Di Lorenzo. 0 Comments

Mit Wise Package Studio 8 wurden 3 Komponenten Attribute der neueren Windows Installer Versionen hinzugefügt, welche wir in diesem Artikel genauer unter die Lupe nehmen:

 

componenteAttribute

msidbComponentAttributesDisableRegistryReflection  (Disable registry reflection)

(Betrifft nur x64 Betriebssysteme)
Dieses Komponenten Attribut deaktiviert die Registry Reflection für alle Registrey Keys der betroffenen Komponente.

Vereinfacht erklärt:

Auf 64-Bit Windows Systemen gibt es 2 Registry Ansichten, eine für 32-Bit und eine für 64-Bit Applikationen.

Dabei unterscheidet man zwischen folgenden 3 Redirection Typen:

  • Shared
    • Gemeinsam verwendeter Registry Key.
  • Redirected
    • 32-Bit / 64-Bit Registry Schlüssel sind separat.
  • Reflection
    • Aus Interoperabilitätsgründen synchronisiert das Betriebssystem gewisse Keys zwischen den Ansichten.

Letztere Methode kann man mit diesem Attribut deaktiviert werden, da dieses Verhalten nicht immer erwünscht sein muss.

Ab Windows 7 / 2008 R2 wurde das Registry Reflection Feature entfernt. Damit wird diese Option für diese Betriebsysteme überflüssig.

Weiterführende Information zum Thema Registry Reflection im Microsoft Developer Network

msidbComponentAttributesUninstallOnSupersedence (Uninstall on supercedence)

Dieses Attribut ist lediglich für  die „Small Patch“ Thematik relevant.

Wir erläutern das ganze einfachheitshalber mit einem praktischen Beispiel:

Wir installieren das Produkt A welches die Komponente Y beinhaltet.

Wir installieren den Patch 1 für das Produkt A, welches als Neuerung eine neue Komponente namens Komponente Z mitliefert. Das Produkt A besteht nun aus Komponente Y & Z

Nun kommen wir zu Patch 2, welcher Patch 1 „superseded“ also ersetzt bzw. überflüssig macht.
Komponente Y wurde in dieser Version aktualisiert und machte dadurch Komponente Z welche in Patch 1 hinzugefügt wurde überflüssig.

Installiert man Patch 2 über das Produkt mit Patch 1 ergibt sich folgendes Resultat:

Aktualisierte Komponente Y.
Komponente Z ist physisch (Files) immer noch vorhanden.

Installiert man hingegen Patch 2 direkt über das Produkt ohne vorher Patch 1 zu installieren ergibt sich folgendes Resultat:

Aktualisierte Komponente Y.
Komponente Z wurde NIE installiert.

Aktiviert man nun bei einer Komponente das „Uninstall on supercedence“ Attribut, überprüft Windows Installer jeweils ob dieser noch notwendig ist & entfernt ihn gegebenen falls.

Bei unserem Beispiel würde das wie folgt aussehen:

In Patch 1 ist für Komponente Z das Attribut gesetzt.

Nun Installieren wir wieder Patch 2, allerdings schaut des Resultat nun anders aus:

Aktualisierte Komponente Y
Komponente Z wurde entfernt

Um das ganze besser veranschaulichen zu können haben wir ein Test-Set mit MSI & Patches realisiert, damit man das Attribut auch in Aktion erleben kann.

Download supersedence.zip

msidbComponentAttributesShared (Shared)

Dieses Komponenten Attribut stellt sicher, dass jeweils die aktuellste Version der Komponente zur Verfügung steht.
Wir erläutern das ganze einfachheitshalber mit einem praktischen Beispiel:

Zuerst wird Produkt A installiert, welches den gemeinsam verwendeten Komponenten Z in der Version 1.0 installiert.

Als nächstes Installieren wir Produkt B mit dem gemeinsam verwendeten Komponenten Z in der Version 1.1.

Nun Installieren wir für Produkt A den Patch X welches den gemeinsam verwendeten Komponenten Z auf die Version 1.2 hebt.

Aufgrund diverser Probleme entscheidet man sich Patch X für Produkt A wieder zu deinstallieren: Während diesem Vorgang wird wieder die alte Version von Komponent Z in der Version 1.0 wiederhergestellt.

Da Produkt B aber explizit auf die Version 1.1 setzt funktioniert dieses nun nicht mehr.

Sobald dieses Attribut bei einer Komponente aktiv ist, stellt Windows Installer jeweils sicher, dass die aktuellste Version eines gemeinsam verwendeten Komponenten auf dem System bleibt.

Wir empfehlen deshalb den Einsatz dieses Attributes für gemeinsam verwendete Komponenten, neben den üblichen “Always Increment shared .DLL Count” & “Leave installed on uninstall” Attributen.

Companion Files

Published on December 23, 2009 in Windows Installer and Windows Installer by Fabio Di Lorenzo. 0 Comments

Oft begegnet man in der Software Paketierung dem Problem, dass man eine unversionierte Datei ersetzen will, dies aber nicht immer auf Anhieb gelingt.

Der Grund ist meist schnell gefunden, die Datei wurde mittlerweile modifiziert oder aus anderen Gründen stimmt das Create/Modified Datum nicht mehr überein. Deshalb verhindern auch die Default File Versioning Rules das erfolgreiche Ersetzen der Datei.

Die Windows Installer Technologie bietet aber hierfür eine elegante Lösungsmöglichkeit an, welche leider oft in Vergessenheit gerät.

Companion Files, zu Deutsch: Begleit-Dateien, bezeichnet man Dateien in der Installation, bei denen man eine andere Datei als “Entscheidungsträger” definiert.

Beispiel:

Für userdata.usr (unversioniert) konfiguriert man “MyVersioned.dll” (versioniert) als “Entscheidungsträger”. Sofern MyVersioned.dll installiert wird (Beispiel: Höhere Version als bestehende MyVersioned.dll), wird auch userdata.usr installiert.

Wise Package Studio kann dies wie folgt realisiert werden:

  1. Man wechselt auf folgende Ansicht:
    “Setup Editor -> Tables -> File”
  2. Als nächster Schritt sucht man sich die unversionierte Datei heraus.
  3. Sobald man diese gefunden hat, öffnet man das DropDown Menu bei der Spalte “Version”.
    companion_files
  4. Bei der Spalte trägt man nun die gewünschte “Entscheidungsträger” Datei ein, diese sollte natürlich optimaler weise eine versionierte Datei sein.

Den Mechanismus in Aktion sieht man entsprechend in der Logfile:

File: C:\Program Files\MyProject\userdata.usr;    Overwrite;    Won’t patch;    Existing file is of an equal version    (Checked using version of companion: C:\Program Files\MyProject\MyVersioned.dll)

Weiterführende Information gibt es natürlich wie immer im Windows Installer SDK:

http://msdn.microsoft.com/en-us/library/aa367997%28VS.85%29.aspx

Aktualisierte Visual C++ 2005 SP1 Merge Module

Published on December 7, 2009 in Windows Installer by Fabio Di Lorenzo. 0 Comments

Bei der Repaketierung von Applikationen welche die Visual C++ 2005 SP1  Runtimes benötigen sollte ein Augenmerk darauf gelegt werden, welche Version exakt benötigt wird.

Denn seit dem 28. Juli existiert eine aktualisierte Variante der “Visual C++ 2005 Sp1 Redistributable” (8.0.50727.4053) unter folgendem Link zum Download:

http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en

Die aktuellste Version von Quicktime (7.6.5) verlangt beispielsweise explizit diese Runtime-Version.
Im Repaketierungsprozess darf man deshalb diese nicht einfach durch die normalen SP1 Merge Module (8.0.50727.762) ersetzen.

Die neuen Merge Module erhält man durch aktualisieren der Visual C++ 2005 Entwicklungsumgebung. Bei diesem Prozess werden die Merge Module im Verzeichnis” %CommonProgramFiles%\Merge Modules” auf den neusten Stand gebracht.
Diese können dann ins repaketierte Projekt hinzugefügt werden und somit entfällt das Redistributable MSI als Installations-Voraussetzung.

Den Patch für die Visual Studio 2005 SP1 Entwicklungsumgebung steht hier zum herunterladen bereit:

http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=7c8729dc-06a2-4538-a90d-ff9464dc0197

Mehr Hintergrundinformationen zur aktualisierten Version gibt es unter folgendem Link:

http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx

TcRTime    TcRTime    128        1    TCRtime.sys
TcIo    TcIo    128        1    TcIo.sys
TcPlc    TcPlc    128        1    TcPlc.sys
TcCam    TcCam    128        1    TCCam.sys
TcRouter    TcRouter    128        1    TCRouter.sys
TcIoPNet    TcIoPNet    128        1    TcIoPNet.sys
TcIoEth    TcIoEth    128        1    TcIoEth.sys
TcIoECat    TcIoECat    128        1    TcIoECat.sys

Exclusion Liste für Windows 7

Published on November 19, 2009 in Best Practices and Wise Package Studio by Stefan Hotan. 0 Comments

Die Software Repaketierung unter Windows 7 baut grundsätzlich auf die gleichen Repackaging Best Practices wie bei Windows Vista auf.

Aus unseren Erfahrungen, die wir bei Windows 7 Migrationprojekten gesammelt haben, empfehlen wir die Ausschlussliste-Liste mit folgenden Einträgen zu erweitern, um eine bessere Qualität des Deltas eines Snap-Shots unter Windows 7 zu erreichen.

Verzeichnis C:\Boot excl. Sub-Directory
Verzeichnis C:\Users\All Users excl. Sub-Directory
Verzeichnis C:\Users\AppData\Local\Temp excl. Sub-Directory
Verzeichnis C:\Users\AppData\LocalLow\Microsoft\CryptnetUrlCache excl. Sub-Directory
Verzeichnis C:\Users\All Users\Microsoft\RAC excl. Sub-Directory
Verzeichnis C:\Users\All Users\Microsoft\Search excl. Sub-Directory
Verzeichnis C:\ProgramData\Microsoft\RAC excl. Sub-Directory
Verzeichnis C:\ProgramData\Microsoft\Search excl. Sub-Directory
Verzeichnis C:\Windows\ServiceProfiles excl. Sub-Directory
Verzeichnis C:\Windows\System32\LogFiles excl. Sub-Directory
Verzeichnis C:\Windows\System32\winevt\Logs excl. Sub-Directory
Datei ntuser.dat.LOG1 File/Wildcard
Datei UsrClass.dat File/Wildcard
Datei UsrClass.dat.LOG1 File/Wildcard
Registry HKCU Software\Classes\Local Settings\MuiCache Ignore entire subtree
Registry HKCU Software\Classes\Local Settings\Software\Microsoft\Windows\Shell Ignore entire subtree
Registry HKLM SOFTWARE\Microsoft\Windows Search Ignore entire subtree
Registry HKLM SOFTWARE\Microsoft\Reliability Analysis\RAC Ignore entire subtree
Registry HKLM SOFTWARE\Microsoft\Windows NT\CurrentVersion\SPP Ignore entire subtree
Registry HKLM SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore Ignore entire subtree
Registry HKLM SYSTEM\CurrentControlSet\services\VSS Ignore entire subtree
Registry HKLM COMPONENTS Ignore entire subtree
Registry HKLM Schema Ignore entire subtree

Weitere Informationen, was bei einer Windows 7 Migration zu beachten ist, können Sie an unserem User Group Meeting erfahren.
Nebst verschiedenen Keynotes zu aktuellen Themen erwarten Sie Technologie- und Produkte-News sowie Live Demos und Praxisberichte. Nutzen Sie die Gelegenheit sich effektiv zu informieren und mit Fachkollegen und Spezialisten zu diskutieren.

usergroup

Internal Error 2709

Published on November 11, 2009 in Best Practices and Windows Installer by Stefan Hotan. 0 Comments

Die Windows Installer 2709 Fehlermeldung ist eine Benachrichtigung, die bei einer Update Installation erscheinen kann. Wird eine betroffene Installation auf einer Clean Machine installiert, so sieht alles gut aus, keine Fehlermeldung erscheint. Sollte die gleiche Installation als Update Installation durchgeführt werden, so erscheint die 2709 Fehlermeldung. Interessant dabei ist, das der Test auf einer Clean Machine eigentlich das gleiche Problem haben sollte, das Problem aber aus internen Abläufen der Windows Installer Session automatisch korrigiert wird.

2709

Das Problem kann unter anderem durch ein Setup-Capture mit Wise Package Studio entstehen, wenn Dateien mit Merge Modulen ersetzt werden. Wie in diesem Beispiel wurde die Datei comdlg32.ocx durch ein Merge Module von Microsoft ersetzt. Dieser Vorgang löscht jedoch nicht die Verweise der bereits erstellten Componenten in der FeatureComponents Tabelle.

FeatureComponent
Komponenten die während einem Setup-Capture mit einem Merge-Module ersetzt wurden, bleiben in der FeatureComponents Tabelle zurück

Das etwas mit diesen Komponenten nicht stimmt, wird in der Tabellenansicht des Windows Installer Editors ersichtlich. Werden diese Einträge übersehen, so wird auf diesen Misstand während der Validierung darauf hingewiesen:
Not a valid foreign key; Table: FeatureComponents, Column: Component_, Key(s): Complete.comdlg32.ocx ice03.html FeatureComponents Component_ Complete comdlg32.ocx
Evaluation: ICE03

Diese Einträge sind aus der FeatureComponents Tabelle zu löschen. Es kann jedoch vorkommen, das die Validierung aus unbekannten Gründen bei dieser Überprüfung fehlschlägt und keine Probleme angezeigt werden. Bei einem anschliessenden Testdurchlauf der Installation wird keine Fehlermeldung erscheinen, da die Windows Installer Session diese fehlerhaften Einträge überspringt.

Doing action: InstallValidate
Feature: Complete; Installed: Absent;   Request: Local;   Action: Local
Component: CreateFolder; Installed: Absent;   Request: Local;   Action: Local
Component: registry44; Installed: Absent;   Request: Local;   Action: Local
Component: findmsm.exe; Installed: Absent;   Request: Local;   Action: Local

Während der InstallValidate Aktion werden die betroffenen Komponenten ausgewählt, die fehlerhaften Einträge werden einfach übergangen.

Soweit scheint alles zu funktionieren, bis zu dem Tag, an dem mit der gleichen Installation ein Update durchgeführt wird. Bei einer Update Installation wird zusätzlich die MigrateFeatureStates Aktion durchgeführt. Diese überprüft die Stati der bereits Installierten Features und vererbt die Feature States bei der Update Installation (Die Vererbung von Feature Stati kann mit der Upgrade Tabelle deaktiviert werden). Die Aktion  MigrateFeatureStates übergeht  die fehlerhaften Einträge in der FeatureComponents Tabelle jedoch nicht und wird mit der Fehlermeldung 2709 die Installation abbrechen.

DEBUG: Error 2709:  The specified Component name (‘comdlg32.ocx’) not found in Component Table.

In diesem Fall sind in der Installation die fehlerhaften Einträge in der FeatureComponents Tabelle zu beheben. Wir empfehlen diese Überprüfung in die Best-Practices von Software-Paketierungs Guidelines aufzunehmen, um diesem Problem zuvor zukommen.

Verzeichnisverfügbarkeit bei Custom Actions

Published on November 9, 2009 in Windows Installer by Stefan Hotan. 0 Comments

Nach den Regeln der alten Windows Installer Schule wird gelernt, das beim Einsatz von Custom Actions Verzeichnisse der Directory Tabelle erst nach der CostFinalize Aktion zur Verfügung stehen.
Demnach sollen Custom Actions, die mit Verzeichnis-Verweise arbeiten, erst nach der CostFinalize Aktion ausgeführt werden.

Die CostFinalize Aktion wird alle Verzeichnisse für die Windows Installer Session bereitstellen.
MSI (s) (F8:E8): Doing action: CostFinalize
MSI (s) (F8:E8): PROPERTY CHANGE: Adding TARGETDIR property. Its value is ‘C:\’.

Interessanterweise kann bei der AppSearch Aktion mit Verzeichnissen wie WindowsFolder und ProgramFilesFolder gearbeitet werden obwohl diese vor der CostFinalize Aktion ausgeführt wird. Dementsprechend gibt es Verzeichnisse die schon vor der CostFinalize Aktion verwendet werden können.

Bei der Analyse einer Log-Datei wird ersichtlich, das vor der INSTALL Session, also noch bevor überhaupt eine Aktion ausgeübt werden kann, alle SpecialFolders (Magic Folders) aufgelöst werden und danach sofort zur Verfügung stehen.

Mit dem APICall SHGetFolderPath werden SpecialFolders aufgelöst.
MSI (s) (F8:E8): SHELL32::SHGetFolderPath returned: C:\Documents and Settings\Administrator\Application Data

Bei der Analyse der Log-Datei, sieht man jedoch den WindowsFolder, SystemFolder und den ProgramFilesFolder nicht aufgelistet. Diese Verzeichnisse stehen wie die restlichen SpecialFolders bei Beginn der INSTALL Session zur Verfügung.

Somit lässt sich aussagen, das SpecialFolders von Beginn der Installation verwendet werden können und Verzeichnisse, welche die Installation selber erstellt, nach der CostFinalize Aktion.

Mit dieser Erkenntnis können viele Custom Actions, welche mit SpecialFolders arbeiten, schon vor der CostFinalize Aktion ausgeführt werden.

Wise Package Studio 8 Download

Published on November 2, 2009 in NEWS and Wise Package Studio by Stefan Hotan. 0 Comments

Das Wise Package Studio 8 wurde wie angekündigt am 29. Oktober 2009 veröffentlicht.

Kunden mit einem laufenden ‘Annual Upgrade Protection’ (AUP) können, nach erhalt des Registrierungscodes der per Email zugestellt wird, die neue Version über das Altiris License Management Portal herunterladen.
Es wird ein neuer Lizenzschlüssel benötigt, dieser kann im License Management Portal mit dem neuen Registrierungscode freigeschalten werden.

Für Evaluationzwecke kann eine Trialversion des Wise Package Studio 8  über die Symantec Homepage bezogen werden:
www.symantec.com/business/package-studio

Als langjähriger Wise Produkte Partner und Wise Added Value Reseller können wir bei einer Evaluation oder Upgrade des neuen Wise Package Studio professionelle Dienstleistungen anbieten.

Das Wise Package Studio 8 Getting Started Guide ist eine hilfreiche Dokumentation zur Installation einer Professional Edition im Serverumfeld.

Eine INI Datei nicht reparieren

Published on October 28, 2009 in Windows Installer by Stefan Hotan. 0 Comments

In dem heutigen Post geht es in der Windows Installer Technologie um die Situation, dass eine INI Datei während einer Reparatur nicht aktuallisiert werden soll.

Das Standard-Verhalten bei einer Reparatur ist wiefolgt: Der Inhalt einer INI-Datei wird mit den Werten aus der INIFile Tabelle verglichen und bei einer Differenz mit den ursprünglichen Werten überschrieben.
Sollte ein Endbenutzer Änderungen an einer INI-Datei vorgenommen haben, so gehen diese bei einer Reparatur des Produktes verloren.

Gemäss der Windows Installer SDK kann über die Aktions-Spalte mit dem Wert 1 festgelegt werden, dass ein Eintrag nur überschrieben wird, falls dieser nicht vorhanden sein sollte. In vielen Fällen wird die Änderung der Aktion die Situation entschärfen, da die Vorgabe auch bei einer Reparatur angewendet wird.

IniFileTable
Mit der Action-Spalte lassen sich zusätzliche Modifikations-Optionen für INI-Dateien einstellen

Betrachtet man die Situation genauer, so kann es sein, dass ein Endanwender Werte aus der INI-Datei löscht. Diese werden bei einer Reparatur wieder hergestellt und verwirft damit die Konfiguration des Endanwenders. Es gibt keine Modifikations-Option die diese Situation berücksichtigt. Eine Möglichkeit bietet die Verwendung einer Kondition in der InstallExecuteSequence Tablle bei der WriteIniValues Aktion. Die WriteIniValues Aktion schreibt die Werte einer INI-Datei anhand der Instruktionen der INIFile Tabelle. Mit der Kondition NOT REINSTALL kann die Aktion bei einer Reparatur ausgelassen werden. Damit geht die Reparaturfunktion aller INI-Dateien verloren, was an dieser Stelle zu erwähnen ist.

INIFile
Bei der Reparatur kann die Modifikation von INI-Dateien ausgeschaltet werden

Sollten die beschriebenen Möglichkeiten keine Alternative zur Situation sein, so stehen weitere Möglichkeiten über Benutzerdefinierte Aktionen (Custom Actions) zur Verfügung. Eine einfache Möglichkeit ohne viel Aufwand mit Scripting-Sprachen zu verbringen bietet der Wise Script Editor. Mit der Funktion Editet INI File kann eine INI-Datei erstellt werden. Die Custom Action ist mit der Kondition NOT Installed  zu versehen, dann wird die Datei nur erstellt jedoch nicht geändert bei einer Reparatur.

Edit
Mit dem WiseScript Editor lassen sich einfach INI-Dateien erstellen.