Hallo zusammen!
In meinem InstallShield-Projekt benutze ich relativ viele InstallScript-Custom Actions (z.B. für Hardware-Checks) mit sehr vielenen Konstanten wie z.B. :
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
InstallScript-Konstanten durch Properties ersetzen
Started by
Michael.Hu
, Jun 17 2008 07:33
2 replies to this topic
Posted 17 June 2008 - 07:33
CODE |
#define CPU_MIN 2000 #define RAM_MIN 1024 ... #define CPU_LOG "Cpu: %s (required: %s MHz, available: %s MHz)" #define RAM_LOG "Ram: %s (required: %s MB, available: %s MB)" ... |
Nun frage ich mich, ob es sinnvoll wäre solche Konstanten im Property Manager als Properties zu definieren um sie zentral verwalten zu können.
Spricht irgendetwas dagegen keine "#defines" mehr zu verwenden und alle Konstanten als private Properties zu definieren? Hat das irgendwelche Nachteile (vielleicht mehr Speicherverbrauch?) oder macht man das eh so?
Danke für eure Tips!
Gruss
Michael
Edited by Michael.Hu, 17 June 2008 - 07:33.
Posted 17 June 2008 - 07:45
Das ist Geschackssache wo Du welche Konstanten ablegst.
Ich würde sie allerdings im Quellcode belassen, denn nur da werden sie ja verwendet.
Ansonsten fragt man sich später, was mach ich wo mit dem Property CPU_MIN?!
Ich würde sie allerdings im Quellcode belassen, denn nur da werden sie ja verwendet.
Ansonsten fragt man sich später, was mach ich wo mit dem Property CPU_MIN?!
Posted 19 June 2008 - 13:55
Hallo, ich habe da auch schon verschiedene Varianten probiert.
- für bestimmte Dinge benutze ich Eigenschaften
(Eigenschaften-Manager / Tbl Property)
(Versionsnummern für Installationspfade, Datum für Wartungsvertrag)
<-- Änderung bei Release bzw. Patches
- In den Scripten, wie von Dir beschrieben.
<-- Änderung nicht immer erforderlich, Voraussetzungen können ja über
mehrere Releases konstant bleiben
- Eine eigene Tabelle einfügen und die Werte bei der Installation bei
Bedarf auslesen mittels Script.
<-- Nachteil:
Hat sich nicht so bewährt, hoher Pflegeaufwand:
Wenn mehrere Setups und Änderung, dann muß jedes Setup angefasst werden.
<-- Vorteil:
Alle Voraussetzungen für eine Installation auf einen Blick.
Dokumentation und auch noch spätere Abfrage der Voraussetzungen über
externes Tool möglich.
<-- Nachteil überwiegt aber.
noch ein Hinweis - Zentrale Stellen für Änderungen die bei jedem Release zu machen sind zu schaffen bzw. beachten, damit man nichts vergißt:
- Produkteigenschaften (Product-, Upgrade-GUID, Version)
- Stringtabellen (Bezeichnungen für Shortcuts, die eine Versionsnummer
beinhalten, stehen bei mir ganz am Anfang z. B. __SC_LinkProgram = PSV 8.59)
Geht leider nicht anders (Oder?).
- Eigenschaften (Eigenschaften-Manager / Tbl Property)
- Upgrades --> MajorUpgrade, Prevent Downgrade
- Releases --> Produktkonfiguration --> Release / Debug, ..., PackageGUID
Ich hätte lieber auch nur eine Stelle.
Vielleicht haben andere noch bessere Ideen.
Gruß
André
- für bestimmte Dinge benutze ich Eigenschaften
(Eigenschaften-Manager / Tbl Property)
(Versionsnummern für Installationspfade, Datum für Wartungsvertrag)
<-- Änderung bei Release bzw. Patches
- In den Scripten, wie von Dir beschrieben.
<-- Änderung nicht immer erforderlich, Voraussetzungen können ja über
mehrere Releases konstant bleiben
- Eine eigene Tabelle einfügen und die Werte bei der Installation bei
Bedarf auslesen mittels Script.
<-- Nachteil:
Hat sich nicht so bewährt, hoher Pflegeaufwand:
Wenn mehrere Setups und Änderung, dann muß jedes Setup angefasst werden.
<-- Vorteil:
Alle Voraussetzungen für eine Installation auf einen Blick.
Dokumentation und auch noch spätere Abfrage der Voraussetzungen über
externes Tool möglich.
<-- Nachteil überwiegt aber.
noch ein Hinweis - Zentrale Stellen für Änderungen die bei jedem Release zu machen sind zu schaffen bzw. beachten, damit man nichts vergißt:
- Produkteigenschaften (Product-, Upgrade-GUID, Version)
- Stringtabellen (Bezeichnungen für Shortcuts, die eine Versionsnummer
beinhalten, stehen bei mir ganz am Anfang z. B. __SC_LinkProgram = PSV 8.59)
Geht leider nicht anders (Oder?).
- Eigenschaften (Eigenschaften-Manager / Tbl Property)
- Upgrades --> MajorUpgrade, Prevent Downgrade
- Releases --> Produktkonfiguration --> Release / Debug, ..., PackageGUID
Ich hätte lieber auch nur eine Stelle.
Vielleicht haben andere noch bessere Ideen.
Gruß
André