Hallo zusammen,
ich hab eine Frage bezüglich InstallShield 2010.
Ich brauche für meinen Installer 2 selbst definierte Felder. Beide Felder bräuchte ich in den CustomActions (bei mir in VBScript geschrieben).
Mein Ziel ist es, einen Rollout-fähigen Installer zu basteln, den man aber auch per Hand starten können sollte. Ist das so überhaupt möglich? Oder muss man dafür voneinander getrennte Installer erstellen?
Der Aufruf im Rollout wird per per Skript-Befehl beim Login von Windows erfolgen.
Momentan schaut der Befehl folgendermaßen aus: "msiexec /i installer.msi /qn".
Kann man so denn auch diese beiden selbstdefinierten Parameter per Parameter in diesen Befehl integrieren?
Gruß
waldek
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.
Eigene Felder im InstallShield-Installer
Started by
waldek
, Jan 11 2010 09:36
18 replies to this topic
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 11 January 2010 - 09:47
Welchen Projekttyp verwendest du? Dann verschiebe ich die Frage ins zutreffende Forum.
Meinst du mit "selbst definierte Felder" Properties (entspricht in entwa Variablen in Programmiersprachen, kann man auf der Kommandozeile setzen und in Custom Actions auslesen)
Meinst du mit "selbst definierte Felder" Properties (entspricht in entwa Variablen in Programmiersprachen, kann man auf der Kommandozeile setzen und in Custom Actions auslesen)
Stefan Krüger
InstallSite.org twitter facebook
waldek
-
- Full Members
- 9 posts
Posted 11 January 2010 - 10:25
Ich verwende InstallShield 2010 Express, falls du das meinst.
Sind diese Properties denn auch dann in der Installationsroutine auch als Felder zu sehen?
Also ich will ein Textfeld haben, wie es z.B. im Bild die Felder im oberen Bereich.
Gruß
waldek
Sind diese Properties denn auch dann in der Installationsroutine auch als Felder zu sehen?
Also ich will ein Textfeld haben, wie es z.B. im Bild die Felder im oberen Bereich.
Gruß
waldek
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 11 January 2010 - 16:47
| QUOTE |
| Ich verwende InstallShield 2010 Express, falls du das meinst. |
Dann entspricht der Projekttyp "Basic MSI". Ich verschiebe die Frage.
Stefan Krüger
InstallSite.org twitter facebook
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 11 January 2010 - 16:50
Jedem Eingabefeld ist ein Property zugeordnet. D.h. wenn man im Dialog-Editor ein Edit-Feld anöegt gibt man dabei auch ein Property an, in dem der eingegebene Wert dann gespeichert wird.
Allerdings gibt es in der Express Edition keinen Dialog-Editor und deshalb auch keine Möglichkeit, zusätzliche Eingabefelder anzulegen. Wenn dir die vorhandenen Dialoge nicht ausreichen, musst du auf die Professional oder Premier Edition wechseln.
Allerdings gibt es in der Express Edition keinen Dialog-Editor und deshalb auch keine Möglichkeit, zusätzliche Eingabefelder anzulegen. Wenn dir die vorhandenen Dialoge nicht ausreichen, musst du auf die Professional oder Premier Edition wechseln.
Stefan Krüger
InstallSite.org twitter facebook
waldek
-
- Full Members
- 9 posts
Posted 12 January 2010 - 10:19
Danke schon mal für die bisheringen Antworten, die haben mir erstmal weitergeholfen. Aber ich habe schon wieder weitere Fragen 
Kann ich denn solche Properties wenigstens erstellen, so dass ich diese per Kommandozeilenaufruf setzen kann/darf aber nicht als Textfeld angezeigt werden sollen?
Kann ich denn solche Properties wenigstens erstellen, so dass ich diese per Kommandozeilenaufruf setzen kann/darf aber nicht als Textfeld angezeigt werden sollen?
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 12 January 2010 - 14:23
Ja, das ist kein Problem. Du musst das Property dazu im Projekt gar nicht definieren, d.h. wenn es nicht auf der Kommandozeile gesetzt wird, existiert es einfach nicht. Beispiel:
Kommandozeile:
msiexec /i installer.msi /qn MEINPROPERTY=irgendwas
Allerdings solltest du im Property SecureCustomProperties dein selbst-definiertes Property mit auflisten.
In der Custom Action dann (z.B. VBScript):
bla = Installer.Property("MEINPROPERTY")
Kommandozeile:
msiexec /i installer.msi /qn MEINPROPERTY=irgendwas
Allerdings solltest du im Property SecureCustomProperties dein selbst-definiertes Property mit auflisten.
In der Custom Action dann (z.B. VBScript):
bla = Installer.Property("MEINPROPERTY")
Stefan Krüger
InstallSite.org twitter facebook
waldek
-
- Full Members
- 9 posts
Posted 15 January 2010 - 11:13
Danke nochmal für die Antwort, die hat mir erstmal wieder gut geholfen :-)
Wie kann ich diese Properties in den SecureCustomProperties reinschreiben? Meine Google - Recherche hat nichts ergeben :-(
Was passiert eigentlich, wenn auf dem Zielrechner schon das selbige Programm installiert ist? Also Ziel von mir ist es, ein Update unsichtbar abzuwickeln bei der Anmeldung des Rechners in der AD-Domäne. Wo müsste ich die CustomAction einsetzen?
MfG
waldek
Wie kann ich diese Properties in den SecureCustomProperties reinschreiben? Meine Google - Recherche hat nichts ergeben :-(
Was passiert eigentlich, wenn auf dem Zielrechner schon das selbige Programm installiert ist? Also Ziel von mir ist es, ein Update unsichtbar abzuwickeln bei der Anmeldung des Rechners in der AD-Domäne. Wo müsste ich die CustomAction einsetzen?
MfG
waldek
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 15 January 2010 - 18:40
| QUOTE |
| Wie kann ich diese Properties in den SecureCustomProperties reinschreiben? |
Im Property-Manager - oder gibt es den in Express nicht?
| QUOTE |
| Was passiert eigentlich, wenn auf dem Zielrechner schon das selbige Programm installiert ist? |
Das kommt darauf an. Wenn die neue Version einen anderen ProductCode hat, dann handelt es sich um ein sog. Major Upgrade, und das läuft normalerwerise automatisch, ohne dass du was machen musst.
Ist der PackageCode gleich, kommt standardmäßig die Fehlermeldung "Eine andere Version ist bereits installiert". Um das zu vermeiden, startest du die neue Version mit Kommandozeilenparametern:
msiexec /i deine.mei REINSTALL=ALL REINSTALLMODE=vomus
Wenn die neue Version eine setup.exe hat, dann wird die typischerweise die Kommandozeilen-Parameter automatisch setzen, d.h. hier genügt es meist, die setup.exe zu starten.
Ist der PackageCode gleich, kommt standardmäßig die Fehlermeldung "Eine andere Version ist bereits installiert". Um das zu vermeiden, startest du die neue Version mit Kommandozeilenparametern:
msiexec /i deine.mei REINSTALL=ALL REINSTALLMODE=vomus
Wenn die neue Version eine setup.exe hat, dann wird die typischerweise die Kommandozeilen-Parameter automatisch setzen, d.h. hier genügt es meist, die setup.exe zu starten.
Stefan Krüger
InstallSite.org twitter facebook
waldek
-
- Full Members
- 9 posts
Posted 19 January 2010 - 13:25
Danke nochmal für die Antwort.
Nach ausgiebiger Erkundung der Express Version habe ich leider keinen Editor für die Custom Properties finden können :-(
Kann man diese irgendwie per Hand setzen?
Was ich im vorigen Post meinte, in welcher CustomAction in der Ansicht von IS würde landen, wenn ich in einem Fall bin, wo das Programm schon installiert ist? Ich möchte ungerne jedes mal bei der Anmeldung das Programm komplett neuinstallieren.
Und wie kann ich das Setup überspringen, wenn das Programm schon installiert ist? Das würde bei mir dann zu treffen, wenn während der Anmeldung in der Domäne das MSI Paket dem User zugewiesen und ausgeführt wird.
Wie kann ich denn in CustomActions die Installation mit Fehlermeldung abbrechen?
Gruß
waldek
Nach ausgiebiger Erkundung der Express Version habe ich leider keinen Editor für die Custom Properties finden können :-(
Kann man diese irgendwie per Hand setzen?
Was ich im vorigen Post meinte, in welcher CustomAction in der Ansicht von IS würde landen, wenn ich in einem Fall bin, wo das Programm schon installiert ist? Ich möchte ungerne jedes mal bei der Anmeldung das Programm komplett neuinstallieren.
Und wie kann ich das Setup überspringen, wenn das Programm schon installiert ist? Das würde bei mir dann zu treffen, wenn während der Anmeldung in der Domäne das MSI Paket dem User zugewiesen und ausgeführt wird.
Wie kann ich denn in CustomActions die Installation mit Fehlermeldung abbrechen?
Gruß
waldek
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 19 January 2010 - 15:09
| QUOTE |
| Kann man diese irgendwie per Hand setzen? |
Wenn IS Express den Property Manager nicht enthält, dann kannst du entweder die erstellte MSI-Datei Nachbearbeiten, z.B. mit Orca oder InstEd, oder die Professional-Version von InstallShield verwenden.
| QUOTE |
| in welcher CustomAction in der Ansicht von IS würde landen, wenn ich in einem Fall bin, wo das Programm schon installiert ist? |
Das ist keine Custom Action.
| QUOTE |
| Und wie kann ich das Setup überspringen, wenn das Programm schon installiert ist? Das würde bei mir dann zu treffen, wenn während der Anmeldung in der Domäne das MSI Paket dem User zugewiesen und ausgeführt wird. |
Ich glaube, ich verstehe dein Szenario noch nicht so ganz. Geht das darum, dass du *das selbe* MSI-Paket erneust startest (warum machst du das?) oder eine neuere Version? Für den gleichen Benutzer oder für einen, der die Software bisher noch nicht installiert hat? Installierst du benutzer-bezogen oder maschinen-bezogen (= für alle Benutzer)?
Stefan Krüger
InstallSite.org twitter facebook
waldek
-
- Full Members
- 9 posts
Posted 19 January 2010 - 15:38
| QUOTE |
Ich glaube, ich verstehe dein Szenario noch nicht so ganz. Geht das darum, dass du *das selbe* MSI-Paket erneust startest (warum machst du das?) oder eine neuere Version? Für den gleichen Benutzer oder für einen, der die Software bisher noch nicht installiert hat? Installierst du benutzer-bezogen oder maschinen-bezogen (= für alle Benutzer)? |
Also folgendes Szenario habe ich: Mein Installer soll ein Addin für Excel installieren. Verteilt wird die MSI Datei über Active Directory. Das bedeutet: Bei der Anmeldung des jeweiligen Benutzers wird die MSI Datei ausgeführt. Aber nur für den jeweiligen Benutzer. Es kann meiner Meinung nach kann ich keine AllUser Installation betreiben, da bisher noch nie angemeldete User, logischerweise nicht in der Registry erfasst sind. Deswegen wird es nur für den aktuellen Benutzer installiert.
Wenn aber an dem Rechner schon mal eine Installation stattgefunden hat, aber noch nicht für den jeweiligen Benutzer, sollen lediglich in einer CA ein Registry Key in dem HKCU gesetzt werden.
Für den Fall, dass eine neue Version fertig gestellt wird, will ich jetzt schon eine Updatefunktionalität einbauen. Daher auch die Frage, was passiert, wenn das Addin bereits installiert ist.
EDIT: Idee dabei ist / war, dass das zu Beginn ein Skript gestartet wird, wo geprüft wird, ob es sich um eine normale Installation oder Update oder Anlegen des jeweiligen Users handelt um dann die entsprechenden Aktionen auszuführen.
Edited by waldek, 19 January 2010 - 17:22.
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 20 January 2010 - 10:48
Wenn das Produkt (also das msi-Paket) für Benutzer A installiert ist und nicht für Benutzer B, dann muss beiom Anmelden von Benutzer B die normale Installation durchgeführt werden.
as reine Nachtragen von HKCU-Einträgen würde nur funktionieren, wenn das Produkt bereits für "alle Benutzer" (ALLUSERS=1) installiert wurde.
Allerdings wird generell davon abgeraten, dieses etzen von HKCU-Einträgen im Installer zu machen, besser direkt in der Applikation oder per Login-Skript. Auf diesem Weg kann man doe HLCU-Einträge ggf. auch wieder entfernen, was bei einer ALLUSERS-Installation problematisch ist.
as reine Nachtragen von HKCU-Einträgen würde nur funktionieren, wenn das Produkt bereits für "alle Benutzer" (ALLUSERS=1) installiert wurde.
Allerdings wird generell davon abgeraten, dieses etzen von HKCU-Einträgen im Installer zu machen, besser direkt in der Applikation oder per Login-Skript. Auf diesem Weg kann man doe HLCU-Einträge ggf. auch wieder entfernen, was bei einer ALLUSERS-Installation problematisch ist.
Stefan Krüger
InstallSite.org twitter facebook
waldek
-
- Full Members
- 9 posts
Posted 28 January 2010 - 15:34
Hallo nochmal 
Hab nochmal 2 Fragen.
1. Frage: Wie ist es denn möglich die Installation abzubrechen? Wenn zum Beispiel ein Fehler in einer CustomAction auftritt, möchte ich die Installation komplett abbrechen.
2. Fragen: In welcher Phase der Deinstallation habe ich Zugriff auf die Windows Installer Datenbank also zum Beispiel InstallDir?
Gruß
waldek
Hab nochmal 2 Fragen.
1. Frage: Wie ist es denn möglich die Installation abzubrechen? Wenn zum Beispiel ein Fehler in einer CustomAction auftritt, möchte ich die Installation komplett abbrechen.
2. Fragen: In welcher Phase der Deinstallation habe ich Zugriff auf die Windows Installer Datenbank also zum Beispiel InstallDir?
Gruß
waldek
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 28 January 2010 - 16:36
1. durch entsprechenden Rückgabewert (siehe Doku, hängt davon ab ob es eine DLL oder eine EXE ist)
2. Die Verzeichnis-Properties müssten spätestens nach CostFinalize zur Verfügung stehen. Allerdings heißt es standardmäßig INSTALLDIR (Groß-/Kleinschreibung beachten)
2. Die Verzeichnis-Properties müssten spätestens nach CostFinalize zur Verfügung stehen. Allerdings heißt es standardmäßig INSTALLDIR (Groß-/Kleinschreibung beachten)
Stefan Krüger
InstallSite.org twitter facebook
waldek
-
- Full Members
- 9 posts
Posted 02 February 2010 - 14:17
Hallo,
Danke nochmal, das hat erstmal weitergeholfen, aber das Abbrechen der Installation bzw. die Bedingung wird in einer VBScript-CustomAction ermittelt.
Ich habe auch gesucht und gefunden, dass man CustomActions Typ 19 benutzen soll, aber ich weiß leider nicht, wie dies aus dem Skript heraus aufgerufen werden muss.
Kann mir jemand sagen, wie das passiert oder ob das überhaupt möglich ist?
gruß
waldek
Danke nochmal, das hat erstmal weitergeholfen, aber das Abbrechen der Installation bzw. die Bedingung wird in einer VBScript-CustomAction ermittelt.
Ich habe auch gesucht und gefunden, dass man CustomActions Typ 19 benutzen soll, aber ich weiß leider nicht, wie dies aus dem Skript heraus aufgerufen werden muss.
Kann mir jemand sagen, wie das passiert oder ob das überhaupt möglich ist?
gruß
waldek
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 03 February 2010 - 17:10
Du kannst entweder in der Custom Action einen Fehler-Returnwert zurückgeben. Dann wird die Instalaltion abgebrochen, allerdings ohne spezifische Fehlermeldung.
Oder du verwendest ein CA vom Typ 19 die du nach der VBScript-Aktion einfügst und mit einem Property als Bedingung versiehst. Dieses Property kannst du dann im Script setzen und so steuern, ob die CA Typ 19 aufgerufen wird oder nicht.
Oder du verwendest ein CA vom Typ 19 die du nach der VBScript-Aktion einfügst und mit einem Property als Bedingung versiehst. Dieses Property kannst du dann im Script setzen und so steuern, ob die CA Typ 19 aufgerufen wird oder nicht.
Stefan Krüger
InstallSite.org twitter facebook
waldek
-
- Full Members
- 9 posts
Posted 22 February 2010 - 15:26
Hallo,
danke nochmal die letzte Antwort hat mir mal wieder gut geholfen.
Und nu kommen wieder weitere Fragen:
Die Installation wird der Repair-Modus gestartet. Es wird alles gelöscht, jedoch nicht "neuinstalliert".
Wie kann das sein und wie kann ich das verhindern? Muss ich irgendwo noch eine CA setzen und da die Installation abbrechen lassen?
Gruß
Waldek
danke nochmal die letzte Antwort hat mir mal wieder gut geholfen.
Und nu kommen wieder weitere Fragen:
Die Installation wird der Repair-Modus gestartet. Es wird alles gelöscht, jedoch nicht "neuinstalliert".
Wie kann das sein und wie kann ich das verhindern? Muss ich irgendwo noch eine CA setzen und da die Installation abbrechen lassen?
Gruß
Waldek
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 22 February 2010 - 18:24
Im Repair-Modus sollte nicht alles gelöscht werden, sondern nur drüber-installiert. Kann es sein, dass mit deinen Feature- oder Komponentenbedingungen was schief geht? Hast du mal eine Logdatei geschrieben?
Stefan Krüger
InstallSite.org twitter facebook