3 replies to this topic

[Marsyas]

Hallo an Alle!

Ich hab ein kleines Problem. Wir wollen für ein existierendes Setup eine neue Version rausbringen. Ich hab dem neuem Setup ein Minor Upgrade hinzugefügt und das Setup lässt sich wie gewünscht, entweder allein oder als Upgrade über eine exitistierende Installation installieren. Die normale Installation funktioniert wie gewünscht, allerdings wurden im Upgrade-Fall Registrywerte, die der Nutzer gesetzt hatte durch die Standardwerte des Setups ersetzt. Das Setup nutzt intern Properties, die in den Dialogen gesetzt werden und in den Components die entsprechenden Registrywerte speichern.

Kein Problem dachte ich mir, liest du halt die ganzen Registrywerte mittels System Search aus und überschreibst die nur mit den Standartwerten, wenn die Dialoge angezeigt werden (dafür ist zum Glück nicht viel zu tun, schließlich werden die Defaultwerte einfach im Propertymanager gesetzt und durch das System Search ersetzt).

Nun tritt aber ein witziges Verhalten auf: Das System Search findet die Werte und das Upgrade funktionert. Dummerweise werden nun aber in der Registry aus DWORD-Werten immer String-Werte a la #100 statt 100, der eigentliche Wert wird somit richtig gesetzt, nur der Datentyp stimmt halt hinten und vorne nicht mehr.

Hab ich irgendwas falsch gemacht oder ist das ein Bug von IS?
Btw, ich nutzte IS 11.5 Premier, die 12er liegt schon neben mir, ist aber noch nicht installiert.

Bitte alles, was irgendwie zum Thema nützlich sein könnte, posten!

Gruß

Marsyas

[Stefan Krueger]

Deine Idee ist schon ganz richtig. Allerdings fügt Windows Installer bei der Systemsuche bestimmte Prefixes zu den Werten hinzu, siehe http://msdn.microsof...cator_table.asp
So wird aus dem DWORD 1 im Property #1.
Wenn du #1 in der Registry-Tabelle stehen hast (InstallShield versteckt das in der Registry-Ansicht, aber schau mal in den Direct Editor) wird wieder DWORD 1 in die Registry geschrieben.
Das Problem entsteht wenn du in der Registry-Tabelle stehen hast:
#[PROPERTY] und PROPERTY auf 1 initialisierst. Bei der erstinstallation wird daraus #1 und alles ist gut. Aber nach der Systemsuche hat PROPERTY den Wert #1 und damit steht in deiner registry-Tabelle auf einmal ##1
Lösung: Initialisiere PROPERTY auf #1 und nimm die # aus der Registry-Tabelle raus.

Wenn du bei der Erstinstallation eine Benutzereingabe ohne # haben willst: nimm für die Eingabe ein anderes Property ANZEIGEPROPERTY das du auf 1 initialisierst. Dann eine Custom Action Typ 51 (Set a Property) die PROPERTY auf #[ANZEIGEPROPERTY] setzt.

Schwierig wird es dann, wenn du auch beim Update nochmal die ausgelesenen Werte in einem Dialog anzeigen willst. Dann musst du eine Custom Action schreiben die das # vornedran weglöscht.

(so ich hoffe das war einigermaßen verständlich, wenn nicht frag bitte nochmal)

[Marsyas]

Hallo Stephan,

danke für die Info, ich habs verstanden und auch umsetzen können. Nun funktionierts, so wie ich will.

Ist dieses eigenartige Verhalten auf einen Fehler von InstallShield oder dem Windows Installer zurück zu führen oder ist das so gewollt?

Gruß

Marsyas

[Stefan Krueger]

InstallShield kann da nichts dsfür, das haben sich die Windows Installer Leute bei Microsoft so ausgedacht, und in gewisser Weise macht es ja auch Sinn (du schreibst #1 rein und bekommst #1 zurück, wobei die # nicht in der Registry landet sondern den Typ angibt). Ist also Absicht.
Ich hätte vielleicht stattdessen ein zusätzliches Feld "Typ" eingefügt anstatt mit Prefixes zu arbeiten. Aber das zieht sich ja überall durch MSI durch: Properties in Großbuchstaben sind public, mit Kleinbuchstaben private. [!Feature] ist der Zustand eines Features, [&Feature] ist die gewählte Aktion, usw.