Wo Programmupdate hinspeichern

[Luckie]

Zitat von hoika:

Hallo,

Zitat:

in einen Ordner unterhalb meiner Exe

Wo liegt denn die Exe?

Die Antwort ist unerheblich. Man weiß nie, wohin der Benutzer die Anwendung hin installiert. Man muss vom schlimmst möglichen Fall ausgehen. Und der wäre, wenn der Benutzer keine schreibrechte in einem Ordner hat zum Speichern des Updates. Zumindest speichern sollte ohne Adminrechte gehen. Wenn dann das Update angestoßen wird, kann das Update nach Adminrechten fragen.

[haentschman]

Zitat:

man erstellt einfach einen dedizierten Ordner %LOCALAPPDATA%\<company>\<Product>\Updates dafür.

+
...nur heißt er bei mir SYSTEM, statt Updates, weil noch andere systemrelevate Sachen drin sind. Der Name ist ja wurscht, der Platz ist entscheidend. Den User Ordner halte ich nicht gut. Da sollten nur die Daten drin sein, die dieser User für sich benötigt.

[Schokohase]

Zitat von haentschman:

Zitat:

man erstellt einfach einen dedizierten Ordner %LOCALAPPDATA%\<company>\<Product>\Updates dafür.

+
...nur heißt er bei mir SYSTEM, statt Updates, weil noch andere systemrelevate Sachen drin sind. Der Name ist ja wurscht, der Platz ist entscheidend. Den User Ordner halte ich nicht gut. Da sollten nur die Daten drin sein, die dieser User für sich benötigt.

Also doch nicht %LOCALAPPDATA%\<company>\<Product>\Updates?

Denn da idR folgendes gilt

Code:

%LOCALAPPDATA% => %USERPROFILE%\AppData\Local
%USERPROFILE% => %HOMEDRIVE%\Users\%USERNAME%

befürwortest du die Verwendung dieses Ordners und gleichzeitig lehnst du diesen ab. Das ist etwas verwirrend.

[haentschman]

Moin...

Zitat:

befürwortest du die Verwendung dieses Ordners

...ähmmm, sorry.
Es ist noch früh am Morgen und zu wenig Koffein. Ich meinte %APPDATA% oder umgangssprachlich ProgramData (gemeinsam für alle User).

[Schokohase]

Zitat von haentschman:

Moin...

Zitat:

befürwortest du die Verwendung dieses Ordners

...ähmmm, sorry.
Es ist noch früh am Morgen und zu wenig Koffein. Ich meinte %APPDATA% oder umgangssprachlich ProgramData (gemeinsam für alle User).

Das sind aber zwei Paar Schuhe.

Bei mir lösen sich diese wie folgt auf:

Code:

%APPDATA% => APPDATA=C:\Users\Schokohase\AppData\Roaming
%ProgramData% => C:\ProgramData

Wenn der Benutzer das Update anstösst, dann sollten die Daten mMn in einen Ordner unterhalb von

Code:

%LOCALAPPDATA% => C:\Users\Schokohase\AppData\Local

wandern und von dort ausgeführt werden. Das wird dann immer funktionieren, selbst wenn sich der Benutzer mit n anderen Benutzern auf einem Terminal-Server tummelt. Der Ordner ist nur für ihn selber und es gibt keine Überschneidungen mit anderen Benutzern.

Die Installation selber kann man dann leicht per Mutex systemweit einzigartig machen. Worst Case können also n Benutzer das Update anstossen, aber nur einer kann es erfolgreich ausführen (wegen dem Mutex).

[haentschman]

Zitat:

Das sind aber zwei Paar Schuhe.

...ich merke schon, die %..% Order sind nicht meine Welt. Ich meinte explizit ProgramData...ich hole mir jetzt mal Kaffee.

[freimatz]

Hallo,
Danke für alle Antworten. Ich nehme dann mal einen Unterordner von TPath.GetTempPath

[freimatz]

Das scheint nun zu funktionieren - zumindest bei den meisten. Bei einem Tester gibt es das Problem, dass er die Datei lädt. Danach liegt auch eine mit dem Namen in dem Ordner, jedoch ist das inhaltlich keine exe sondern eine HTML. Darin steht u.a.:

While trying to retrieve the URL: <meine exe> The content is blocked due to the following condition:

Your organization's Internet access policy suggests you should not be downloading this file type. You may proceed with this download at your own discretion. ...
<a class="orange" href="http://passthrough.fw-notify.net/proceed?extension=exe&filename=...

Mein Programm startet dann die "Exe", was dann nicht funktioniert.

Der Tester hatte zwar einige Vorschläge, aber was meint Ihr?

[mensch72]

ne "exe" irgendwo per WEB hinspeichern schägt auf gut gesicherten Sytemen fehl... das ist auch gut so!

Wenn eh die eigene Applikation das "Update" startet, kann man es auch via "PNG" in einem binary ZIP-TAG unterbringen... das klappt sogar auf Apple OSx&IOS Systemen.
Ich nutze wenn irgend möglich nur noch zipped binary MetaDatenTags via JPGs oder PNGs, nen schickes kleines ICON als echte Bilddaten dazu und es flutscht locker überall in den Dokumenten/Bild Ordner... Endungen wie "exe" oder was auch immer sehen StandardOS-Nutzer doch seit langem nicht mehr... aber die Mini-Vorschau für Bilddateien kennen "alle"!

Bilddateien als zipped binary Container zu mißbrauchen ist nicht ganz die feine Art, aber zumindest bei PNGs ist das sogar gemäß strenger Apple Richtlinien 100% erlaubt, weil so im PNG Standard echt vorgesehen und von Apple voll unterstützt!

=> es kommt aus meiner Sicht also nicht wirklich darauf an "wo" man etwas speichert, sondern viel wichtiger ist "wie" man etwas speichert!

[Schokohase]

Wenn du den Response-Header auswerten würdest, dann würdest du unterscheiden können, ob du jetzt das Update bekommst, oder eben so ein HTML.

Bei Update -> speichern und Update ausführen
Bei HTML -> anzeigen

In diesem Fall kann der Benutzer wohl über diesen die EXE herunterladen, muss das Update dann aber manuell durchführen.