Je nach Packaging Umgebung kann dies jedoch enormen Aufwand bedeuten.

Mit folgendem Trick kann man sich diesen Aufwand allerdings sparen:

- Installiere den Network Client der 8.0 Version auf einer sauberen VM/Client

- Exportiere danach den “Wise Solutions” Registry key. In diesem Key sind die neuen Lizenzinformation drin. Ohne diese lässt sich WPS 8.0 nicht starten.

- Erstelle ein neues WiseScript und füge mittels “Edit Registry” Aktion diese Keys hinzu

- Als 2 Aktion füge eine “Run Executable” Aktion hinzu, und zeige dort auf die  “PackageStudio8.exe” Executable auf dem Wise Package Studio Share.

- Kompiliere ein neues Executable und lege dies im Wise Package Studio Programmverzeichnis als “PackageStudio7.exe” ab

Nun wird bei alten Netzwerk Client Installationen die PackageStudio7.exe gestartet, welche die benötigten Registrierungsschlüssel für das Wise Package Studio 8 ins Benutzerprofil schreibt und danach die aktuelle PackageStudio8.exe startet.

Mit der Version 4.6 findet nun auch native x64 Technologie Einzug in die Virtualisierungslösung von Microsoft.

Herunterladen lässt sich die neuste APP-V Version über die gängigen Seiten/Zugriffsmöglichkeiten:

• Technet
• MSDN
• MVLS

Die Ontrex AG bietet umfangreiche Consulting und Paketierungs-Diensleistungen für diese Technologie an.
Weitere Informationen über unsere Dienstleistungen finden Sie auf unserer Homepage.

Wie die REMOVE Kondition optimal eingesetzt wird entscheidet die Feature Struktur eines Produktes. Eine einfache Aussage wie REMOVE~=”ALL” zu verwenden, ist keine gute Idee, da es Situationen gibt, wo diese Kondition nicht greift.

Fact ist, dass die REMOVE Kondition im Falle einer Deinstallation verwendet werden kann.
Fact ist, dass bei einer repaketierten Applikation, im Generellen die Kondition REMOVE verwendet werden kann.

Der Ausdruck REMOVE~=”ALL” hat sich über ein Jahrzehnt stark verbreitet. Der Wert ALL bedeutet, dass alle Features eines Produktes deinstalliert werden, sprich die Installation wird komplett deinstalliert. Dies ist die allgemeine Annahme in der Software Paketierung.

REMOVE~=”ALL” wird jedoch nicht in allen Situationen funktionieren, wie es Heath Stewart schon angedeutet hat. Es gibt eine Situation, den Wartungsmodus um es genau zu benennen, wo diese Kondition nicht greift. Betroffen davon sind besonders Software-Entwickler, da dessen Deinstallationen öfters mit dem Wartungsmodus durchgeführt werden und von diesem Problem betroffen sind.

Ein Produkt  kann über folgende vier Wege deinstalliert werden.

Deinstallation mittels Befehlszeile (msiexec.exe -x <product code> /qb) wie gewöhnlich ein Produkt automatisch deinstalliert wird:
MSI (s) (28:5C): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Deinstallation über Control Panel > Add or Remove Programs, wie es ein Endanwender eine Deinstallation durchführen wird:
MSI (s) (28:F8): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Deinstallation über den Wartungsmodus einer MSI Installation (Modify, Repair oder Remove Option im Setup Wizard)
MSI (s) (28:5C): Command Line:
MSI (c) (28:1C): Switching to server: REMOVE=Complete
MSI (s) (28:10): PROPERTY CHANGE: Adding REMOVE property. Its value is ‘Complete’.
MSI (s) (28:10): PROPERTY CHANGE: Modifying REMOVE property. Its current value is ‘Complete’. Its new value: ‘ALL’.
Property(S): REMOVE = ALL

Deinstallation über die Windows Installer API
MSI (s) (28:EC): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Es wird nun ersichtlich, das eine Deinstallation über den Wartungsmodus anders abläuft als die restlichen Deinstallationswege. Beim Wartungsmodus steht es von beginn an nicht fest, welche Windows Installer Aktion der Anwender ausüben wird. Daher kann die REMOVE Property nicht  von Beginn an definiert werden.
MSI (s) (28:5C): Command Line:

In der REMOVE Property stehen alle Feature Namen des aktuell installierten Produktes (Features werden mit ; getrennt falls mehrere installiert sein sollten).
MSI (c) (28:1C): Switching to server: REMOVE=Complete
MSI (s) (28:10): PROPERTY CHANGE: Adding REMOVE property. Its value is ‘Complete’.

Anhand der Windows Installer SDK steht fest, das der Remove Control Event das Argument ALL  dem REMOVE Property der Installations-Session weiter geben muss, damit das gesamte Produkt deinstalliert wird.
MSI (s) (28:10): PROPERTY CHANGE: Modifying REMOVE property. Its current value is ‘Complete’. Its new value: ‘ALL’.
Property(S): REMOVE = ALL

Entscheidend ist, die Action InstallValidate erkennt den Remove Control Event Eingriff  und ändert den Wert in der REMOVE Property auf ALL.

Dies bedeutet: Wird ein Produkt über den Wartungsmodus deinstalliert, so werden Konditionen mit dem Argument REMOVE~=”ALL” erst nach der InstallValidate Aktion funktionieren.

Sollte früher eine Aktion diese Kondition verwenden, so wird diese nicht ausgeführt.

Sie erhalten in  Wise Package Studio beim kompilieren von virtuellen Projekten (WVP) im “Virtual Package Editor” nachfolgende Fehlermeldung:

Das erstellte VSA Paket an sich funktioniert, allerdings wird die Package GUID nicht korrekt gesetzt.

Lösung:

Das Problem taucht nur auf wenn der Wise Package Studio Server auf einem x64 OS installiert wurde.

Die “VPE_SVSZip.dll” Komponente, welche die Datei SVSZip.dll beinhaltet,  wird nur auf 32-Bit  Systemen installiert da diese mit “NOT VersionNT64″ konditioniert ist.

32-Bit Network Clients, welche nahezu sämtliche Programme vom Server aus abrufen, benötigen aber diese DLL um das VSA korrekt abschliessen zu können.

Am einfachsten installieren Sie einen Testserver auf ein 32-Bit OS und kopieren danach die “SVSzip.dll” ins “Virtual Package Editor” Verzeichnis.

Ein ‘Reinstall’ wird jedoch nicht durchgeführt. Das Java Setup wird die bestehende Installation deinstallieren und die gleiche Intallationsrutine erneut aufstarten.

Der Grund dieses Vorgehens liegt im Design der Installation. Es handelt sich bei der Java Installation um keine echte Windows Installer Rutine, sondern die MSI Technologie wird verwendet um Basis Dateien zu installieren, welche durch Benutzerdefinierte Aktionen (Custom Actions) die Hauptinstallation durchführen.

Ein fataler Nebeneffekt besteht nun, wenn eine Repartur oder die Installation ein zweites mal im unbeaufsichtigten Modus  durchgeführt wird.
Anstelle einer Reparatur, wird eine fehlerhafte Neuinstallation durchgeführt.

Ein Blick hinter die Kulissen zeigt, das nicht alle Benutzerdefinierten Aktionen ausgeführt werden.

Fatal: Basis-Dateien wie java.exe werden aus dem System32 Verzeichnis gelöscht und die Java Runtime ist nicht mehr funktionsfähig.

Wir empfehlen daher, die Intallation mittels Transformationsdatei anzupassen, damit dieser unerwünschte Vorgang unterbunden wird.

Folgende Eintäge in der Custom Action Tabelle sind nötig:

 Die InstallExecuteSequence Tabelle mit der Kondition:

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:

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

Das Resultat nach der Installation ist wie folgt:

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:
   
5. Zum Schluss müssen noch die neu erfassten Custom Actions in der InstallExecuteSequence eingebaut werden. Fügen Sie folgende neue Zeilen hinzu:
   

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.

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.

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

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.

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”.
   
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

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