Prüfmethoden für Updates

[TheMiller]

Hallo,

nach einer längeren - berufsbedingten - Abstinenz von Delphi, melde ich mich nun wieder zurück!

Ich überlege gerade, ob es nicht an der Zeit wäre, meinen bis jetzt funktionierenden Updater etwas zu verbessern und wollte mich daher mal nach anderen Funktionsweisen erkundigen. Derzeit funktioniert mein Updater wie folgt: Es wird lokal geprüft, welche Programmdateien existieren, welche Versionsinformation jeweils einkompiliert wurde und dazu noch der md5-Hash einer Datei erzeugt. Danach wird auf dem Update-Server eine ini-Liste heruntergeladen und die lokale mit remote-Liste abgeglichen. Alle Dateien, die remote einen anderen md5-Hash, eine andere Versionsnummer haben oder lokal nicht existieren, sind sind upzudaten. Ich dachte damals, dass man so manipulationen an Dateien ausschließen kann.

Doch irgendwie scheine ich der einzige zu sein, der Updates am md5-Hash ermittelt. Gibt es einen Grund dafür, welche andere Systeme/Merkmale gibt es, wie handhabt ihr die gesamte Update-Prozedur (von Erstellen/Publizieren, bis zur Prüfung und Installation).

Mal wieder "Danke im Voraus"

[himitsu]

Och, ich glaub nicht, daß du da der Einzige bist, mit dem MD5 Hash. :angel:

Andere Merkmale:
- Dateidatum (Erstellung/Änderung) und Dateigröße
- Versionsinfo in der Datei (zumindestens bei den EXEn und DLLs, oder wo man noch Extra-Infos aus der Datei auslesen kann, wie z.B. JPEG und MP3)


Manche gucken aber garnicht in die Datei.
Vielleicht die installierte Programmversion aus der Registry oder einer INI lesen und dann blind alles runterladen, wenn es eine neue Programmversion gibt
Wobei sich ja einige Dateien/Programme selber prüfen, z.B. über eine Signatur, so daß man selber den Hash weglassen könnte, also nur auf die Versionsinfo gucken, und den "Hash" erst zur Laufzeit prüfen lässt.

[sx2008]

Zuerst die Steuerdatei herunterladen; wenn das nicht klappt braucht man gar nicht erst weitermachen.
Dann Dateilänge vergleichen zwischen lokaler Datei und dem Wert in der Steuerdatei.
Bei Abweichung braucht man den Hash nicht mehr zu prüfen.
Hashverfahren:
* MD4 - ist schneller als MD5, kann aber leichter gefälscht werden. Bei einem normalen Updater dürfte das aber kein Problem sein
* MD5, SHA1 - für Updater gut geeignete Standardverfahren.
* SHA256 - für erhöhte Scherheit
* CRC32 - schnell, aber der Hashraum ist mit 32 Bit zu klein

Nach dem Herunterladen nochmals den Hash ermitteln um Übertragunsfehler auszuschliesen.
Alle Dateien zuerst in temporäres Verzeichnis runterladen damit man bei einem Verbindungsabbruch nicht mit einer unvollständigen Installation dasteht.
Erst nachdem alle notwendigen Dateien heruntergeladen wurden die lokalen Dateien updaten.

PS: es empfiehlt sich das Hashverfahren mit einem fremden Tool zu überprüfen.
http://www.hashemall.com/

[himitsu]

Zitat:

Zitat von sx2008 (Beitrag 1269287)

Nach dem Herunterladen nochmals den Hash ermitteln um Übertragunsfehler auszuschliesen.

Wenn das übertragungsprotokoll das schon erledigt, dann wäre das unnötig.

Und das mit dem halben Update:
Es ist möglich die Datei- und Registryzugriffe in einer Transaction zu behandeln. (zumindestens im NTFS, wo sonst auch, weiß ich nicht)
Auch bietet Windows einen netten Hintergrundübertragungsdienst an, für Download/Updates, was bei größeren Programmen recht nett ist, da wird Windows gebeten die Datei zu laden und wenn sie da ist, wird das eigene Programm darüber informiert/gestartet.
Und ich finde es immer wieder krank, daß Updater sich als eigener ständig laufender Service installieren, wo doch ein Updater schöner wäre, wenn er sich als geplanter Task anmeldet, welcher z.B. einmal am Tag/Woche/Monat kurz gestartet wird, bzw. z.B. auch beim Start des Computers. (k.A. warum vorallen bei großer Software sowas nicht endlich mal durchsetzt und eventuell auch über einen gemeinsamen Updater, damit nicht jedes Programm selber nachsehn muß)

> regelmäßig und bei passenden Events starten lassen > schauen ob es ein Update und eventuell mit Installation vergleichen > wenn nichts los ist, dann gleich wieder beenden > Windows das runterladen lassen > Update-Quelldateien prüfen > Programm-Installation prüfen (Dateien korrekt und Programm eventuell nicht aktiv, falls der Updates dann nicht möglich wären) > Transaktion starten > Installation/Update starten > eventuell nochmal alles prüfen > Transaktion abschließen oder bei einem Fehler zurücksetzen > fertig


Bei einer Transaktion könnte man das vorherrige Prüfen sich auch sparen, also die Dateien nicht doppelt behandeln und einfach gleich alles machen ... bei einem Problem lässt es sich ja wieder komplett zurücksetzen und bei der vorherrigen Prüfung vergisst man sowieso bestimmt irgendeinen SonderProblemfall. :stupid:

[Sir Rufo]

• Updater als geplanter Task
  Das diese Möglichkeit nicht genutzt wird liegt daran, dass der Updater mit Admin-Rechten laufen muss. Ein geplanter Task kann das, aber wenn das Kennwort für den Account geändert wurde, dann lief der Task nicht mehr. Neuere Versionen von Windows (ab Vista? auf jeden Fall ab Win7) haben das Problem nicht mehr.
  
  Mal sehen, ob sich da etwas ändert, wenn XP so langsam verschwindet (verschwindet es wirklich?). Bis dahin ist das also keine empfehlenswerte Option.
• Updater als Dauerdienst
  Ist wohl ein Märchen, dass ein Dienst dauernd laufen muss, aber ein vernünftig geschriebener verbraucht eigentlich so gut wie keine nennenswerte Ressourcen.
• Genereller Updater
  Hier wäre MS eigentlich der richtige Initiator. Aber die haben doch dafür schon lange was im Säckel:
  MSI-Pakete und die Gruppenrichtlinien in Verbindung mit einer Domäne. Ok, das ist eher im gewerblichen Umfeld anzutreffen und die Kontrolle hat der Domänenverwalter (was auch gut ist).
  
  Die neueren Versionen (>Win8) haben ja jetzt auch einen AppStore und da sind Updates auch kein Problem mehr.

Ich frage mich gerade, warum hier überhaupt von einzelnen Dateien gesprochen wird und nicht von einem Setup-Paket. Nur so kann man doch gewährleisten, dass alle zusammengehörigen Teile zuverlässig ausgeliefert werden, sich an der richtigen Stelle befinden und auch alte obsolete Dateien von der Platte verschwinden. Wer Angst vor zu großen Setup-Dateien hat kann ja auch spezielle Update-Pakete schnüren (würde ich trotzdem nicht empfehlen, da idR Pflege-Aufwand und Nutzen in keinem angemessenen Verhältnis stehen). Zusätzliche Treiber, Bibliotheken, etc. können vom Setup auch noch bei Bedarf nachgeladen und installiert werden.

In dem Fall kann dann auch der Updater selber strunz-doof sein (Auf neue Version prüfen, Setup laden, Setup ausführen) und der wird auch das wildeste Update hinbekommen - weil diese Aufgabe das Setup übernimmt.

[TheMiller]

Hello!

Danke für die Antworten. Also handhaben wir das alle ähnlich/gleich. Allerdings gefällt mir die Idee mit einer "Setup"-Datei, welche die Update-Daten beinhaltet. Das erspart wirklich sehr viel Arbeit und mit Inno-Setup lässt sich ja auch viel Logik umsetzen. So kann man bequem Rollouts veröffentlichen, ohne vorher umständlich ein Update schnüren und verschiedene Dateien in verschiedene Verzeichnisse hochladen zu müssen. Ich glaube, das werde ich in Zukunft so machen.

Nur eine Frage habe ich trotzdem noch: Macht es Sinn bzw. hat es nennenswerte Vorteile, die Hashes der Programmbestandteile mit den Online-Hashes abzugleichen, oder reicht wirklich die Speicherung der Versionsnummer? Ich tue mich mit dem Gedanken schwer, die Hashes nicht zu vergleichen. Einerseits kann es sein, dass die Versions-Datei nicht den reellen Wert wiedergibt. Zudem werden Benutzer vllt. doch davon abgehalten, an den Dateien Manipulationen vorzunehmen, da sie sonst keine Updates mehr machen können. Was denkt ihr dazu?

[Namenloser]

Ich sehe persönlich nicht so den Sinn, beim Updaten die Hashes zu vergleichen. Du musst jedes mal alle Programmdateien einlesen, selbst wenn sich beim Update nur eine Datei geändert hat. Das macht den Update-Vorgang unnötig langsam und rechenintensiv.

Wenn der Nutzer unbedingt an den Dateien rumpfuschen will, dann soll er doch. Überhaupt sehe ich das eher als eigenständiges Problem an. Wenn du es wirklich verhindern willst, dass der Nutzer die Dateien verändert, dann solltest du es regelmäßig prüfen, und nicht nur beim Updaten.

[Mavarik]

Warum getrennt?
Warum als Dienst?

Eine Update.Exe als Resource mit in die Exe.
Hauptprogramm "kennt" seine eigene Version und die der DLL's

Dateien runterladen, Update.exe auf die Platte schreiben und mit Admin Rechten starten.


Mavarik

[Dejan Vu]

DLL-Abhängigkeiten, Versionitis usw. bleiben bei einer selbstgebauten Lösung auf der Strecke.

Man vergleicht die Hashs nicht wegen der Manipulation, sondern ob ein Update überhaupt stattfinden muss. Einige verwenden die Versionsnummer oder das Datum, aber eine allgemeine Lösung wird eben den Hash nehmen bzw. ihn anbieten. Wieso soll ich als Programmierer gezwungen sein, eine Versionsnummer einzuführen? Was ist, wenn sich die Größe nicht ändert, weil ja nur der MwSt-Satz von 19 auf 20% erhöht wurde? Was ist, wenn das Erstelldatum der Datei immer der 18.3.1963 ist, weil der Chef das so will?

[himitsu]

Zitat:

Zitat von Mavarik (Beitrag 1269540)

und mit Admin Rechten starten.

Darum nimmt man oft einen Dienst.

z.B. siehe Firefox

Der Firefox schaut nach, ob es eine neue Version gibt (anhand der Versionsnummer), läd das Setup runter und übergibt es dann an den Service, welcher standardmäßig inaktiv ist und dann manuell vom Firefox gestartet wird, falls nötig.
Der Sevice übernimmt nun das Installieren und somit ist keine Adminabfrage mehr nötig. (z.B. für Rechner, wo der Benutzer keine Adminrechte besitzt)

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1269574)

Darum nimmt man oft einen Dienst.

Na toll... wenn Jede Software auf meinem Rechner einen Dienst für Updates starten würde wäre mein Rechner schon ausgelastet. :stupid:

Ne Spass bei Seite... Aber wenn eine Software XY immer einen Dienst installieren würde... No go...

Mavarik

[himitsu]

Joar, drum wäre es schon schön, wenn sich mehrere Programme einen gemeinsamen Updater teilen würden.

Aber Firefox/Thunderbird nutzen einen "gemeinsamen" Service, welcher standardmäßig inaktiv ist und so keinerlei Resourcen verbraucht (außer auf der Festplatte) und der sich nach dem Update auch wieder beendet.
> Mozilla Maintenance Service > Starttyp = manuell > wird bei Bedarf vom Firefox gestartet, nachdem das Update gefunden und runtergeladen wurde

Im Gegensatz dazu z.B. der schrottige Acrobat-Updater (OK, nach einer Woche Laufzeit 00:00:00 CPU und knapp 4 MB RAM, aber wenn das jeder so macht, dann läppert es sich dennoch)
> Adobe Acrobat Update Service > Starttyp = Automatisch > immer durchgehend aktiv

Der Adobe-Flash-Updater ist aber auch standardmäßig aus. :gruebel:

Der Windows Update Service liegt dabei schon bei 'ner 1/4 Stunde und belegt 50 MB.
Bei 10 solchen Updatern wäre das ja nur ein halbes GB und fast 3 Stunden verschwendete Rechenzeit = 22 Minuten pro Tag.

Und so selten wie ich OpenOffice verwende, hab ich erstmal deren mistigen Beschleinigungsdienst entfernt (so wie auch von anderen Programmen), welcher deren Dateien schön im Cache hält und so andere Dinge runterwirft, nur um dann schneller starten zu können.

[QuickAndDirty]

Es ist in gewissen Szenarien sinnvoll im Update/Setup die Hashs aller ausgelieferten Dateien mitzuführen und vor dem Update zu prüfen.
Auf diese Weise kann man z.B. feststellen ob ausgelieferte Dateien verändert wurden. Evtl. hat es die Anwender ja viel Mühe gekostet diese anzupassen.

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1269628)

Aber wenn eine Software XY immer einen Dienst installieren würde... No go...

Was passiert, wenn der Benutzer selbst die Updates starten oder bestätigen muss sieht man ja oft auf PCs, die Virenbefall haben... ich zumindest. Uralter Firefox, bei dem es schon reicht auf eine befallene Seite zu gehen, usw.
Deshalb kann das ja optional sein, aber standardmäßig ist das besser als ohne.

[himitsu]

Bei Programman die man oft nutzt, die ständig neuen Gefahren ausgesetzt sind und die man standardmäig sowieso immer aktuell halten sollte, ist ein AutoUpdater schon sinvoll.
(der sich auch abschalten lässt, für die, welche unbedingt nicht wollen)
> das UAC stört nicht ständig
> und die ohne nötige Rechte ... da muß immer jemand Anderes das machen
> ohne UAC müsste man ständig manuell nachsehn

[Dejan Vu]

Wie immer kommt es auf den Einzelfall an:
a) Kommerzielle Software, die auf anonymen Rechnern mit diversen Rechteszenarien läuft?
b) LOB-Software im Betrieb in einem homogenen Sicherheitskontext?
c) Individualsoftware bei wenigen Kunden?

An einen Update-Service würde ich bei b) und c) nicht mal denken (d.h. ausschließen aber auch nicht).
Selbst bei a) würde ich persönlich von einem Dienst abraten, einfach weil ich die Rechner der Kunden mit Zusatzprogrammen nicht zumüllen will. Natürlich haben die ihre Berechtigung und es ist nur dieses sehr subjektive Argument, welches mich zum 'Gegner' von Updateservices macht.

[TheMiller]

Hallo und danke für die vielen Antworten. Konnte leider nicht eher antworten - was das Wochenende im Urlaub.

Einen Update-Service werde ich nicht programmieren/installieren. Update-Dienste halte ich nur bei Programmen sinnvoll, die weit verbreitet und beliebte Angriffsziele sind, z.B.: Flash, Java, Browser etc.

Ich habe mich entschieden, die Updates über einen Installer auszurollen. Bei Programmstart wird die aktuell installierte Version über eine Datei ausgelesen, mit dem Server verglichen und das dazugehörige Update heruntergeladen. Die Installationsdatei wird geöffnet und erledigt die notwendige Logik. Der Updater ist also - wie vorgeschlagen - "dumm". Um Manipulationen zu verhindern, wird das jeweilige Programm die Hashes in zufälligem Intervall vergleichen. Dabei soll dies keine Umsetzung eines Kopierschutzes sein.

Im Vergleich zu meiner bisherigen Lösung sollte diese nun viel leichter zu verwalten sein. Zwar war die Prüfung pro Datei eine funktionierende Lösung, aber wirklich umständlich zu benutzen.

Demnach wird es demnächst so von statten gehen:

1. Programmiererzeugnisse und Abhängigkeiten in den Release-Ordner verschieben (wenn nicht bereits getan)
2. Rollout erzeugen (zB: via InnoSetup)
3. via Oberfläche eine update.ini erzeugen und automatisch veröffentlichen lassen
4. Benutzer startet sein Programm
5. Updater vergleicht remote-Versionskennung (aus updates.ini) mit lokaler Versionskennung aus Datei/DB. (Versionskennung könnte Build-nr, timestamp etc. sein)
6. Wenn sich diese unterscheiden, läd der Updater das Rollout herunter (Datei entimmt er der updates.ini)
7. Nach dem Download wird das Rollout mittels Hash verifiziert.
8. Das Rollout wird installiert bzw. Daten werden entpackt (je nachdem ob portable oder fest installiert)
9. Programm wird wieder gestartet.

Habe ich etwas wichtiges vergessen oder nicht bedacht? Das müsste doch eigentlich so in Ordnung und dennoch recht flexibel sein, oder?

Danke!

[Dejan Vu]

Gibts da nix Fertiges? Wenn nicht, wäre das nicht mal ne Idee?

[TheMiller]

Ich habe schon mal was fertiges gesehen, aber ich glaube, das kostet Geld. Ich programmiere das mal soweit fertig, wenn Interesse besteht kann ich es ja vllt. teilen.

[generic]

Zitat:

Zitat von Dejan Vu (Beitrag 1269805)

Gibts da nix Fertiges? Wenn nicht, wäre das nicht mal ne Idee?

Einen universellen Updater gab es mal von InstallShield. Der konnte auch mehrere Programme mit Updates versorgen.
http://consumer.installshield.com/work_um.asp

Das Windows Update lässt sich auch übrigens erweitern, allerdings kann ich nicht sagen ob das wirklich für eigne Updates taugen wird (ohne Domäne).

[FBrust]

Hallo,

Zitat:

Zitat von DJ-SPM (Beitrag 1269803)

1. Programmiererzeugnisse und Abhängigkeiten in den Release-Ordner verschieben (wenn nicht bereits getan)
2. Rollout erzeugen (zB: via InnoSetup)
3. via Oberfläche eine update.ini erzeugen und automatisch veröffentlichen lassen
4. Benutzer startet sein Programm
5. Updater vergleicht remote-Versionskennung (aus updates.ini) mit lokaler Versionskennung aus Datei/DB. (Versionskennung könnte Build-nr, timestamp etc. sein)
6. Wenn sich diese unterscheiden, läd der Updater das Rollout herunter (Datei entimmt er der updates.ini)
7. Nach dem Download wird das Rollout mittels Hash verifiziert.
8. Das Rollout wird installiert bzw. Daten werden entpackt (je nachdem ob portable oder fest installiert)
9. Programm wird wieder gestartet.

Ich mache es derzeit genauso (allerdings ohne Hash, aber diese Anregung nehme ich gerne mit). Ich habe mir einen "Uploader" geschrieben, der aufgrund der Programmversion im Release-Ordner die update.ini erzeugt und Setup-Programm und ini-Datei auf einen Server hochlädt.

Unterscheidungsmerkmal ist dabei die Build-Nummer, d. h. bei jeder Programmversion, die veröffentlicht wird, muss zwingend die Buildnummer erhöht werden.

Setups werden auch mit Innosetup erzeugt.

Das Programm startet nach dem Herunterladen das Setup im Silent-Modus, d. h. das Setup läuft zwar sichtbar, aber ohne Eingriffsmöglichkeit (ist ja nur ein Update) durch und startet danach das Programm wieder.

Das alles läuft seit ca. 5 Jahren ohne Probleme.

Gruß
Frank

[Thomas_K]

@Frank "Zwischenzeitlich sind neue Beiträge geschrieben worden."

So grob wie das DJ-SPM hier beschreibt hab ich das hier am Laufen - nur erstmal nur im Intranet. Ach ich verwende innosetup für die "donkey work".

Ich verzichte/vereinfache ein paar Dinge. Es gibt bei mir kein einständiges Update-Hilfs-Programm, sondern der Update.ini check machen die Programme selbst, in einem extra Threads (Objekt Orientiert). Innosetup führt schon eine Integritätsüberprüfung selbständig durch, schlecht ist aber auch nicht das nochmal zu kontrollieren. Es besitzt ein silent bzw. ein verysilent Installations-Modus, von dem ich regen Gebrauch mache (Parameter stehen in den Update.ini(s)) , außerdem lassen sich weitere Kommandozeilenparameter auswerten, die am Ende des automatischen Setups das Programm wieder selbständig starten lässt, zusammen mit einem Kommandozeilenparameter (‚/update‘), der wiederum dafür sorgt, dass eine Erfolgsmeldung angezeigt wird, die der Anwender nur noch ab nicken brauch. Der Vorgang dauert im Allgemeinen hier nur wenige Sekunden.

Es gibt auch keine Zwei verschiedene Setup.exe(s) sondern update - und reguläres Setup ist ein und dieselbe Datei. Mit Innosetup brauch man auch nicht unbedingt in das Programm-Files, sondern automatisch unter appdata installieren, wenn der Anwender eh keine Admin-Rechte besitz, so brauch man auch niemanden bei jedem Update zu Bitten und Betteln.

[Sir Rufo]

Zitat:

Zitat von FBrust (Beitrag 1269837)

Unterscheidungsmerkmal ist dabei die Build-Nummer, d. h. bei jeder Programmversion, die veröffentlicht wird, muss zwingend die Buildnummer erhöht werden.

Genau da halte ich mich eher an die hier beschriebene Vorgehensweise.
Die Auslieferung erhöht die Hauptversions-, Nebenversions- oder Revisions-Nummer.

Die Buildnummer ist hier eher unwichtig. Zur Auslieferung wird dann im VCS auch ein entsprechendes Tag gesetzt (1.0.0, 1.0.1, 1.1.0, ...)

[FBrust]

Hallo,

@Thomas K: Ich hatte keinen roten Kasten.

Ansonsten verwende ich auch nur eine Setup.exe die nach Bedarf mit Parametern aufgerufen wird.


Gruß
Frank

[Thomas_K]

Zitat:

Zitat von FBrust (Beitrag 1269846)

Hallo,
@Thomas K: Ich hatte keinen roten Kasten.
Frank

Aber ich und ich wollte/konnte auch nix mehr Ändern bzw. Bezug auf deine Antwort nehmen - sorry.

[FBrust]

Hallo,

Zitat:

Zitat von Thomas_K (Beitrag 1269861)

Aber ich und ich wollte/konnte auch nix mehr Ändern bzw. Bezug auf deine Antwort nehmen - sorry.

Ach so, dann ist ja gut :)

Gruß
Frank

[TheMiller]

So, mein Updater ist nun fertig. Ich werde ihn noch etwas testen und dann - wenn Interesse besteht - mit euch teilen. Ich habe eine Demo-Applikation geschrieben, ein RolloutMaker zum Erstellen von Updates und alles ist via DoxyGen dokumentiert.

Der Updater, bestehend auf 4 Klassen, kann derzeit folgendes:

• Simple Einrichtung: Die Update-Suche und das Downloaden ist in 10 Codezeilen durch Benutzung der Update-Klasse vollständig konfiguriert.
• Simples Erstellen von Rollouts: Mit 3 Klicks ist das Rollout erstellt und veröffentlicht.
• Automatisches Erstellen der lokalen Versionsdatei, welche zum Vergleich dient.
• Automatische Suche nach Updates. Versionserkennung anhand einer (selbstdefinierbaren) Versionsnummer. Sie muss nicht einkompiliert sein.
• Updates herunterladen (eigener Thread). Indy-Events OnWork etc.pp. werden durchgereicht, sodass die Stati und Fortschritte in der GUI anzeigbar sind.
• ReleaseNotes publizieren und anzeigen.
• Erstellen eines Updates: 3-Klick-System. Der RolloutMaker läd das Projekt, liest die neuen Infos aus, erstellt die Steuerdatei und lädt die Daten automatisch per FTP an ihren Platz (eigener Thread). Auch hier werden alle Events durchgereicht. Die FTP-Einstellungen werden in den Projekteinstellungen definiert.
• Durch den Aufbau des Updaters und der lokalen Versionsdatei ist es möglich, ein zentrales Update-Programm für mehrere eigene Produkte zu erstellen.

Das waren jetzt alle Highlights, glaube ich. Klar kann man immer etwas verändern, aber so funktioniert es erstmal. Bei Interesse lade ich es gerne mal hoch.

Auf diesem Wege möchte ich damit erstmal für die Hilfe, Anregungen und Ideen bedanken.

[Dejan Vu]

Ersetzt Du die Dateien direkt? Was passiert beim Verbindungsabbruch? Funktioniert dann alles noch?
Oder war das nur missverständlich formuliert?

Zitat:

...und lädt die Daten automatisch per FTP an ihren Platz (eigener Thread).

[sh17]

Um noch einmal den Streitpunkt "Update als Service" aufzugreifen:

Welche Möglichkeit gibt es denn noch, es dem Benutzer einer Anwendung so einfach wie möglich zu machen?

Als Beispiel, meine Anwendung besteht aus einem Service, der irgendwo auf einem Server rumdümpelt.
Der hat manchmal nicht mal einen gescheiten Monitor, geschweige denn kommt da jeder Anwender ran.

Meine Idee ist nun, einen zweiten Update-Service daneben zu installieren, der den Hauptdienst überwacht
,ggf beendet und aktualisiert. (Meinetwegen auch per anstubsen vom Benutzer) Mit dem Update werden noch
die Client-Pakette bereitgelegt, die sich dann die Clients beim nächsten Anmelden über einen Starter
vom Server herunterladen und installieren. So hab ich doch ein recht gutes System, was sich selbst
verteilt und sehr wenig Eingriffe vom Benutzer benötigt. Die haben nämlich in der Regel keinen Admin
an der Seite.

Ich würde sogar noch soweit gehen, das der Updater von uns als Anbieter ferngesteuert werden kann, wenn der
Kunde das möchte (in der Regel stimmen sie zu, sie wollen so wenig wie möglich machen,
außer einfach die Software verwenden). Mit noch ein paar kleinen Tests könnte man die Installation
noch auf Fehler prüfen und wir können eingreifen.

Aber wenn wer noch eine andere Idee hat, ich bin interessiert.

[Barthiboy]

Hallo,
ich würde Interesse an dem Updater anmelden.
Gibt es irgendwo ein Repository oder einen Link, wo ich ihn herunterladen kann?
Danke

Gruß
Christian

Das waren jetzt alle Highlights, glaube ich. Klar kann man immer etwas verändern, aber so funktioniert es erstmal. Bei Interesse lade ich es gerne mal hoch.

Auf diesem Wege möchte ich damit erstmal für die Hilfe, Anregungen und Ideen bedanken.[/QUOTE]

[generic]

Du antwortest auf einen Beitrag von 2015.

Ich glaube die Diskussion ist nicht mehr zeitgemäß.
Entweder werden APPs durch die entsprechenden Shops aktualisiert oder durch Paketmanager wie chocolatey.

Du kannst dir sowas aber auch einfach selbst bauen:
https://www.youtube.com/watch?v=MjRV...ytnR44RzYx-aoo

[dummzeuch]

Zitat:

Zitat von generic (Beitrag 1492964)

Ich glaube die Diskussion ist nicht mehr zeitgemäß.
Entweder werden APPs durch die entsprechenden Shops aktualisiert oder durch Paketmanager wie chocolatey.

Äh, nein.

Das gilt vielleicht für die "walled Garden" Betriebssysteme und Linux aber nicht für Windows. Und schon gar nicht für Win32 Programme, wie man vor kurzem lesen konnte.

[generic]

Zitat:

Zitat von Golem.de

Der Microsoft Store wird für diverse neue Programmformate geöffnet - darunter Java-, UWP und eben auch klassische Win32-Apps im .exe-Format.

https://www.golem.de/news/windows-11...07-158459.html

[himitsu]

MS hat aber auch keine andere Wahl.

Gut, man hatte quasi versucht damit die Entwickler zu einer bestimmten Platform zu drängen,
aber für die Akzeptanz eines Shopsystems müssen sie andere etablierte Platformen auch unterstüzen.

Ansonsten holen sich die fremden Paketmanager immer mehr Marktmacht.