ein Fass nach dem anderen geht auf

[jziersch]

Den Pfad zu Deinen Dateien könntest Du doch mit System.SysUtils.GetHomePath ermitteln.

Nachinstallieren von runtimes ist natürlich schwierig - ich würde ich einfach ein Innosetup script verwenden welches dann im selben Pfad Deine module schreibt. Es wird dies automatisch tun, wenn Du den selben "AppName" verwendest.

InnoSetup ist super. Ich verwende allerdings eine ältere Version da der Windows Defender bei der neuen gemotzt hat.

[Redeemer]

%APPDATA% ist das neue C:\. Viele Programme installieren sich heute in %APPDATA%. Chrome und Firefox (non-ESR), auch Entwickler-Sachen wie Sourcetree. Weder zur Installation noch Deinstallation braucht man Rechte. Dass das ganze Programm dann in einer Domäne bei jedem Login und Logout mit einem Server gesynct wird - drauf geschissen. Die haben wohl auch alle keinen Bock darauf, ihr Programm vernünftig zu schreiben und anzupassen.

[freimatz]

Ach so ist das. Das habe ich sogar schon bei einem Microsoft-Tool so gesehen.

@jziersch: das Fass habe ich schon geleert

@MyRealName: InnoSetup u.a. taugen für mich nicht. Spätestens bei der Deinstallation ist das das Problem, dass die gar nicht wissen (können) welche Dateien alle weg müssen. Das hängt sehr von der Art der Instllation und weiss allein mein Code. Klar, auch mit den Tools kann man scripten, aber dann muss ich ja wieder das lernen. Zu Beginn hat ich auch ein Installationstool eingesetzt.

[Delphi.Narium]

Nur mal so hingedaddelt:

Kann Dein Programm sich nicht selbst deinstallieren?

Eine Option dafür einbauen, die alles, was zur Laufzeit entfernt werden kann, entfernt.

Für die Sachen, die nicht entfernt werden können ein Script / Batch, ... schreiben und diese in der Registry unter

Code:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

oder 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

eintragen. (Run and RunOnce Registry Keys)

Was dort steht, wird einmalig beim nächsten Systemstart ausgeführt.

Wenn's z. B. 'ne Batch ist, kann die sich selbst zur Laufzeit löschen und damit wäre alles restlos weg.

Sie könnte auch ein von Dir erstelltes Deinstallationsprogramm starten, warten bis das fertig ist, es löschen und sich dann selbst löschen.

Wenn's sehr anwenderspezifisch ist, kann man auch ein Programm in den Autostartordner legen, beim nächsten Systemstart / Anmelden wird das dann ausgeführt. Es muss halt "nur" sichergestellt werden, dass sich das dann selbst aus dem Autostartordner löscht.

Achso: Das sind nur unausgereifte Ideen, die eventuell 'nen Ansatz liefern könnten (oder aber auch nicht )

[Michael II]

Ich nutze die aktuelle InstallAware Developer und bin zufrieden damit.
Das Ding kann natürlich installieren, deinstallieren, signieren, automatisch (auch im Hintergrund) updaten.

Es gibt sicher andere gute...

(MSIX Packaging Tool ist je nach Umfang u.U. auch interessant. Das Tool kann auch ein bestehendes Setup in ein MSIX File wandeln.)

[TurboMagic]

Zitat von freimatz:

Ach so ist das. Das habe ich sogar schon bei einem Microsoft-Tool so gesehen.

@jziersch: das Fass habe ich schon geleert

@MyRealName: InnoSetup u.a. taugen für mich nicht. Spätestens bei der Deinstallation ist das das Problem, dass die gar nicht wissen (können) welche Dateien alle weg müssen. Das hängt sehr von der Art der Instllation und weiss allein mein Code. Klar, auch mit den Tools kann man scripten, aber dann muss ich ja wieder das lernen. Zu Beginn hat ich auch ein Installationstool eingesetzt.

InnoSetup benutzt Pascal Skript und ein Ereignis zum Deinstallationszeitpunkt sollte einfach sein. Evtl. ein eigenes kleines Konsolenprogramm schreiben welches das Löschen dieser Zusatzmodule macht. Das dann in dem Event aufrufen. Sollte eine Skriptzeile sein.

[generic]

Ich persönlich bin ein Fan vom Windows Installer und dem WIX-Toolset.

https://wixtoolset.org/

Tutorial:
https://www.youtube.com/watch?v=m3lDzMl3Hq0

[TigerLilly]

Mit Inno-Setup geht das wirklich gut:

https://jrsoftware.org/ishelp/index....ldeletesection
https://jrsoftware.org/ishelp/index...._uninstallable
https://jrsoftware.org/ishelp/index....criptuninstall

[Codehunter]

Windows hat irgendwo eine eigene API um Dateien, die aktuell verwendet werden, für die Löschung beim nächsten Systemstart vorzumerken. Vor unendlich langer Zeit hatte ich dafür in DelphiWorks eine Funktion gemacht. Keine Ahnung ob das heute noch funktioniert.

Die Unsitte, ganze Programme nach %APPDATA% zu installieren, kenne ich auch von vielen Programmen. Meist sind es solche, die X-Plattform sind und sich kaum an die historisch verworrene Ordnerstruktur von Windows anpassen lassen.

Letztendlich hat Microsoft das Problem aber selbst geschaffen! Historischer Rückblick aus meiner Erinnerung:

• 1985: Programme installieren sich unter DOS nach C:\Programmname
• 1990: Programme unter Windows 2.x installieren sich nach C:\Programmname
• 1995: Programme unter Windows 95 installieren sich nach C:\Programmname
• 1999: Programme unter Windows 98 installieren sich unter C:\Programme\Programmname
• 2001: Programme unter Windows XP installieren sich unter C:\Program Files\Programmname und werden über Symlinks nach C:\Programme\Programmname gemappt
• 2007: 32-Bit-Programme unter Windows Vista installieren sich unter C:\Program Files (x86)\Programmname, werden über Symlinks nach C:\Programme (x86)\Programmname gemappt und von der UAC gegängelt
• 2007: 64-Bit-Programme unter Windows Vista installieren sich unter C:\Program Files\Programmname, werden über Symlinks nach C:\Programme\Programmname gemappt und von der UAC gegängelt
• 2009: Programme unter Windows 7 installieren sich häufiger unter C:\Program Files\Programmname, weil beide Systemvariablen %PROGRAMFILES% und %ProgramW6432% dorthin verweisen und die UAC dort nicht drauf schaut
• 2012: Programme unter Windows 8 (insbesondere Treiber-Installer) installieren sich unter C:\Programmname, weil die UAC mittlerweile auch auf %PROGRAMDATA% und %PROGRAMFILES% achtet
• 2015: Programme installieren sich unter %APPDATA% und damit auf Multi-User-Arbeitsplätzen gleich mehrfach, weil die UAC bei Installern anschlägt, die Pfade wie C:\Programmname verwenden

Also ich finde das alles Quark im Quadrat. Mittlerweile ist sogar die halbe Systemordnerstruktur gemappt. Teilweise erscheinen im Explorer Einträge wie C:\Programme sogar doppelt (!!!) wobei einer auf C:\Program Files mappt und der andere mit einem "Zugriff verweigert" versandet.

Das einzig Gute an der heutigen Situation ist, dass nach und nach alle älteren Windows-Installationen abgelöst werden und sich auf Windows 10 vereinheitlicht. Doch was soll das Theater mit der UAC in den Programmordnern? Was hat es bitteschön mit Sicherheit zu tun, sich an bestimmten Ordnernamen hochzuziehen? Eigentlich ein Armutszeugnis an Microsoft, dass es da überhaupt Unterscheidungen braucht. Für mich die logische Konsequenz, dass entweder A) die Softwareanbieter auf weniger supportanfällige Ordnerstrukturen ausweichen oder B) die Anwender die UAC abklemmen oder C) beides eintritt.

Persönliche Meinung: Beruflich entwickle ich für Windows und sehe all die praktischen Probleme. Privat nutze ich nur noch Linux. @Embarcadero: Packt endlich den Linux-Compiler in alle Delphi-Editions rein und übernehmt CrossVCL ins RAD Studio! Zum Bsp. im öffentlichen Bereich, bei Verwaltungssoftware, wo Delphi noch häufig zum Einsatz kommt, geht der Trend eindeutig weg von Windows. Da wartet keine Softwarebude mehr, dass sich Emba irgendwann mal auskekst, sondern da wird bei älteren Projekten entweder auf Lazarus migriert oder bei neueren Projekten gleich auf Java o.ä. gesetzt.

[jaenicke]

Zitat von Codehunter:

Letztendlich hat Microsoft das Problem aber selbst geschaffen!
[..]

C:\Program Files bzw. c:\programme kam mit Windows 95 parallel mit der Registry (und danach kam dann das Mapping und intern wurde nur noch das englische Verzeichnis verwendet). Hätten damals alle Entwickler die vom System vorgegebenen Möglichkeiten zur dynamischen Bestimmung des Ordners für die Installation von Programmen verwendet, wären danach auch keine Anpassungen nötig gewesen, auch nicht durch die Umleitungen. Auch die Speicherung von Daten im Programmverzeichnis war schon mit Windows 95 nicht mehr vorgesehen. Es haben nur viele trotzdem gemacht und sich dann gewundert als mit Vista der Pfusch dann aufgefallen ist...

Die Ursache ist nicht nur bei Microsoft zu suchen, sondern vielmehr bei Unwissenheit oder Ignoranz vieler Entwickler. Denn viele haben es ja auch noch weiter so gemacht als man es ihnen schon längst gesagt hatte. Das sieht man ja an den diversen Fragen zu Workarounds statt richtiger Lösungen.

Zitat von Codehunter:

Also ich finde das alles Quark im Quadrat. Mittlerweile ist sogar die halbe Systemordnerstruktur gemappt. Teilweise erscheinen im Explorer Einträge wie C:\Programme sogar doppelt (!!!) wobei einer auf C:\Program Files mappt und der andere mit einem "Zugriff verweigert" versandet.

Dann ist Windows einfach ungünstig konfiguriert. Standardmäßig ist das nicht so.
Wenn man nicht nur versteckte Dateien und Ordner anzeigen lässt, sondern auch geschützte Systemdateien, dann bekommt man eben auch Einträge, mit denen man nichts anfangen kann...

(Das hat sich aber auch geändert. Anfangs fielen auch Einträge unter Systemdateien, die man vielleicht mal sehen wollte. Aber seit Windows 7 oder 8 gibt es so gut wie nie einen Fall, in dem es sinnvoll ist auch geschützte Systemdateien einzublenden.)