12 replies to this topic

[Tlorenzo]

Hallo,

wir haben momentan im Unternehmen zum Erstellen von Setuproutinen das InstallShield Professional 6.30 Standard Edition von 2001 im Einsatz. In den letzten 4-5 Jahren gab es für unsere Bedürfnisse auch keinen Grund ein Update zu kaufen, allerdings sieht es nun im Hinblick auf Vista etwas anders aus.

Könnt ihr mir sagen ob sich diese Installshields auch unter Windows Vista weiterhin korrekt installieren lassen?

Mein Budget ist relativ schlank und deshalb möchte ich mir einen evtl. Neukauf für knapp 2000,- € sparen. Einen aktuellen Vista PC habe ich allerdings auch noch nicht hier... hat jemand von euch schon Erfahrungswerte damit gesammelt?

Danke!

MfG Tlorenzo

[Stefan Krueger]

Microsoft hat bei Vista einige Tricks eingebaut damit auch alte Setups noch laufen, könnte also gut sein dass es geht - sofern du dir niciht selbst ein Bein stellst etwa bei der Windows Versionsabfrage. Offiziell unterstützt wird Vista von IS Pro 6.x natürlich nicht, wenn also was schief geht stehst du im Regen.
Ich hab's noch nicht ausprobiert und kann dir deshalb nicht sagen ob es Probleme gibt.

[m.mueller]

ich habs ausprobiert und festgestellt, dass zumindest die auswahl von betriebssystemen für dateigruppen scheinbar ein problem bereitet.

war windows XP noch, aufgrund der tatsache dass es die versionsnummer NT 5.1 trug, mit windows 2000 gleichgestellt, so ergibt sich nun mit vista ein problem, denn vista trägt die versionsnummer NT 6.0.

Dateien, die bei Vista installiert werden sollen, müssen also in einer Dateigruppe mit der Einstellung OS Independent liegen, was wiederum zu Problemen führen kann, wenn man dieselbe Installation auch für Windows ME/98/95 verwenden will.

[matze.glatze]

Hallo,
auch wir benutzen die 6.3 und ich muss leider sagen, dass es Probleme gibt.
Das kleinere Übel ist die Betriebssystemabfrage - das kann man noch mit "Betriebssystemunabhängig" umgehen. Das weit größere Übel ergibt sich in Zusammenhang mit der BDE5.1. Rein generell läuft alles problemlos, wenn man allerdings das ganze deinstallieren will -wir machen das mit
if (AskYesNo(@DEL_DATA , YES) = YES) then
DeleteDir ( TARGETDIR , ALLCONTENTS );
endif;
also einer Nachfrage ob die Datenbank gelöscht werden soll, werden die Dateien in dem Installationsordner scheinabr gelöscht (im Explorer nicht mehr sichtbar). Installiert man dann die Software inklusive der Datenbanken, sind die alten Daten noch immer vorhanden. Das ganze scheint mit der Auflösung des Ordners "Programme", also dem Standardapplicationpath zu tun zu haben, denn der wird Vista intern immer auf Program Files umgebogen. Versucht einfach mal den Ordner Program Files in C: zu erstellen
Installiert man nun die Anwendung in ein anderes Verzeichnis, z.B. c:\Test funktioniert alles ganz normal wie immer. Es scheint fast so, als ob die Program Files in einem gekapselten Modus verwaltet werden. Man kommt (bis jetzt) einfach nicht an die Datenbank heran.
Falls jemand einen Tip hat, wie ich trotz einer Installation nach C:\Programme alles löschen kann wäre ich sehr dankbar.
Zur Info: wir nutzen Windows Vista Ultimate mit Adminrechten. Die Installs erstellen wir auf WinXP Sp2 - keine Ahnung ob das was ändern würde wenn man auch auf Vista die installs erstellt.

Mittlerweile weiss ich schon mehr: in
User/[Nutzername]/AppData/Local/Virtual Store/Program Files/[Programm]
liegen alle Anwendungsdaten. D.h. alles was man ändert wird dort gespeichert. Das ganze ist Teil des Sicherheitskonzeptes von Microsoft, bei dem Programmdaten von Anwendungsdaten getrennt werden sollen. Zu dumm wenn man eine Datenbank hat, auf die jeder User zugreifen soll und dann auch noch ein InstallShield 6.3 benutzt. Angeblich soll die aktuelle Version 12 damit keine Probleme mehr haben und eben auch neben <Targetdir> auch <AppData> enthalten.
Das ganze kann man aber wie oben erwähnt umgehen, indem man in ein anderes Verzeichnis als [Programme] installiert. Allerdings finde ich es sehr problematisch den Nutzern feste Pfade aufzuzwingen. Ich muss nun wohl oder übel ein Deinstallationsscript schreiben, dass halt manuell die Database aus dem Virtual Store löscht.

Edited by matze.glatze, 19 March 2007 - 09:41.

[Marsyas]

[Stefan Krueger]

Benutzerdaten, also auch die Datenbank selbst, gehören nichts ins Programmverzeichnis. Die Umleitung, die Vista da macht ist der Versuch, auch alte Programme die sich nicht an diese Regel halten noch unter Vista lauffähig zu machen.
Die Folge ist allerdings, dass jeder Benutzer seine eigene Kopie der Datenbank bekommt. Ich vermute mal das ist bei dir nicht gewollt.
Die saubere Lösung wäre, die Datenbank in ein Verzeichnis zu installieren wo alle Benutzer Schreibrechte haben. Ggf. muss dafür auch die Anwendung angepasst werden.

[Krumpschmid]

Hallo,

bin über Umwege auf dieses Forum und auf diesen Beitrag gestoßen.
Wir haben mit unserer Applikation auch das oben beschriebene Problem mit AppData\Local\VirtualStore ... es hat lange gedauert, bis wir dahintergekommen sind, wie der Hase läuft.

Zu den obigen Vorschlägen:
(1) Natürlich läuft es, wenn man mit der rechten Maustaste und den Administratorenrechten die Applikation startet ... das wollen wir aber den Anwendern nicht zumuten und wäre uns auch zu riskant; würden Anwender das nur einmal vergessen, entstünde das totale Chaos ...
(2) Einen anderen Pfad wollen wir nicht nehmen; wir verwenden bei unserer Applikation seit elf Jahren den Standartpfad C:\Programme\UnsereApplikation; würden wir nun umstellen, würde das einge hundert Installationen betreffen.

Wir haben nun folgendes ausprobiert:
* Im Explorer mit rechte Maustauste auf das Verzeichnis C:\Programme\UnsereApplikation
* Eigenschaften
* Sicherheit
* Bearbeiten (Berechtigungen ändern)
* Gruppen oder Benutzernamen: Benutzer (...)
* Berechtigung für den Benutzer: Vollzugriff
* Mit OK bestätigen

Ergebnis:
* Man kann die Applikation starten, ohne mit rechter Maustaste die Administratorenrechte aktivieren zu müssen.
* Es gibt kein Problem mehr mit diesem skurilen Pfad (AppData\Local\VirtualStore...)

Anfragen:
* Da wir unseren Anwendern nicht zumuten wollen, diesen Vorgang manuell durchzuführen, bitten wir um eine Anleitung, wie man mit InstallShild 12 Express die Freigabe dieser Sicherheitsrechte weitergeben kann ... wir hoffen natürlich, dass dies dynamisch für den vom Benutzer ausgewählten Installationspfad gilt.
* Was ist ein TrustInfo Manifest? Siehe dazu http://blog.m-ri.de/...ammieren/vista/, wo zu diesem Problem ganz unten (abschließend) empfohlen wird, sich "schleunigst das entsprechende Trustinfo Manifest nachzurüsten"
* Wenn jemand eine gänzlich andere Idee hat, wie man dies in den Griff bekomment, sind wir für jede Anregung dankbar.

LG Markus Krumpschmid

Edited by Krumpschmid, 12 July 2007 - 21:31.

[Krumpschmid]

[Stefan Krueger]

Um es nochmal deutlich vorweg zu sagen: Benutzerdaten im Programmverzeichnis abzulegen ist der FALSCHE Weg. Mit anpassen der Applikation meinte ich: dafür sorgen, dass nur die Programmdateien im Programmverzeichnis liegen und die Benutzerdaten in ein anderes Verzeichnis geschrieben werden.

Wenn's denn unbedingt sein muss: Man kann mit Windows Installer Rechte auf Verzeichnisse vergeben, so wie du das manuell gemacht hast. In Professional/Premier geht das in der Ansicht Ordner und Dateien mit Rechtsklick auf das Verzeichnis. Ob das auch in Express geht weiss ich nicht. Das Endergebnis ist jedenfalls ein Eintrag in der Tabelle LockPermissions in der .msi Datei.

Mit TrustInfo Maniufest ist denke ich ein noprmales Manifest gemeint, das Informationen zum Required Execution Level enthält. Wenn du dort Admin-Rechte anforderst kommt beim Programmstart aber der UAC-Dialog, ähnlich wie bei "als Admin ausführen".

[Krumpschmid]

Hallo Stefan,

danke für deine Antwort.
Schlußendlich haben wir uns entschieden, es so zu machen, wie du es empfohlen hast:
Programmdateien und Benutzerdaten in unterschiedliche Verzeichnisse ...

Wie findet man im InstallShild 12 Express den Pfad auf "Eigene Dateien" des aktuellen Benutzers?

Verwendet man die Variable PERSONAL FOLDER wird folgender Verweis auf den aktuellen Benutzer gegeben: C:\Users\Markus Krumpschmid\Documents

Welche Variable müssen wir verwenden, um zu folgendem Ergebnis zu kommen: C:\Users\Markus Krumpschmid

LG Markus

Edited by Krumpschmid, 12 September 2007 - 18:59.

[Stefan Krueger]

Dafür gibt es in Windows Installer glaube ich keine vordefinierte Variable. Laut Microsoft soll man SHGetKnownFolderPath oder SHGetFolderPath in einer Custom Action aufrufen, um solche Pfade zu ermitteln. Denn es gibt wohl auch keine Umgabungsvariable dafür.

[Stefan Krueger]

Halt, da war ich auf dem falschen Dampfer. Wir sprechen ja hier über InstallScript, nicht über Windows Installer.
Ich verschiebe die Frage jetzt mal ins richtige Forum.
Aber ich glaube auch im InstallScript gibt es dafür keine Variable, also doch wieder die zuvor genannten APIs aufrufen.

[Krumpschmid]

Hallo Stefan,

danke für die fachkundige Antwort!

LG Markus