[VB.NET] Update-functionaliteit

[Gimmeabrake]

Ik zit me al een tijdje af te vragen hoe ik een programma van mij het beste kan uitbreiden met update-functionaliteit. Het eerste wat in mij opkam was om een soort van update manager te maken, een aparte executable. Inbouwen in de main-executable was natuurlijk geen optie omdat de exe dan zichzelf zou moeten kunnen herschrijven. Het probleem met een aparte executable is echter dat hij weinig communicatiemogelijkheden heeft met de main-executable. Dit lijkt me niet fijn voor de gebruiker.

Om dit probleem op te lossen heb ik de volgende constructie in gedachten: ik maak 2 interfaces, een voor het programma en een voor de update manager. Vervolgens maak ik van het programma en de updater class libraries die deze interface inheriten. Om het programma te starten heb ik een launcher, deze laadt het programma en de updater uit de desbetreffende dll-bestanden. De update procedure ziet er ongeveer zo uit:
- Update manager vindt en download update
- Update manager is klaar met downloaden, geeft sein aan launcher
- Launcher laat programma weten dat update binnen is
- Programma geeft gebruiker de keuze om nu, later of nooit te updaten(in dit geval kiest hij ervoor om meteen te updaten)
- Programma geeft keuze door aan launcher
- Launcher sluit programma en update manager
- Launcher voert update uit (de dll's van het programma en de update manager zijn immers niet meer in gebruik)
- Launcher start desgewenst programma weer op

Dit lijkt mij de beste aanpak, aangezien ik hiermee eigenlijk alle wezenlijke bestanden kan vervangen, en de mogelijkheid heb om het allemaal gebruikersvriendelijk te maken. Zijn er mensen die ervaring met update-systemen hebben? Zo ja, kan het makkelijker? Zijn er dingen waar ik op moet letten als ik dit in de praktijk omzet?

[whoami]

ClickOnce al eens bekeken ?

[sopsop]

Ben je bekend met clickonce? http://visualbasic.about.com/od/usingvbnet/a/clkone01.htm

Damn you whoami

[ Voor 14% gewijzigd door sopsop op 24-04-2009 15:23 ]

[ThaStealth]

ClickOnce vind ik persoonlijk een onpraktische oplossing,
In de eerste plaats al omdat je .Net 3.5 (en een goed geconfigureerde server) nodig hebt om ClickOnce in bijv. Firefox te laten werken (.NET 2.0 werkt alleen maar goed met IE).

Ik zou het zonder de launcher.exe doen. nadeel hiervan is dat je deze niet meer kan updaten. Je zou het als volgt kunnen aanpakken:

main.exe start en runt de CheckUpdate() functie in de updater.exe.
Als CheckUpdate() true retourneert dan doe je (afhankelijk van user settings) de mogelijkheid bieden om de app te updaten. Als de gebruiker hiervoor kiest doe je hetvolgende:
-updater.exe starten
-main.exe sluiten

updater alles laten downloaden + updaten. (muv de updater.exe zelf, de update van updater.exe hernoem je naar updater.new oid). Nadat updater.exe klaar is laat je hem de main app runnen. Main app controleert of er een updater.new is met een bep signature, is dat zo, verwijder updater.exe en hernoem updater.new naar updater.exe. En voer vervolgens de checkupdate functie weer uit.

[Gimmeabrake]

ThaStealth schreef op vrijdag 24 april 2009 @ 16:13:
ClickOnce vind ik persoonlijk een onpraktische oplossing,
In de eerste plaats al omdat je .Net 3.5 (en een goed geconfigureerde server) nodig hebt om ClickOnce in bijv. Firefox te laten werken (.NET 2.0 werkt alleen maar goed met IE).

Inderdaad. Ik compileer mijn programma al met opzet in .Net 2.0 omdat dat op de meeste computers wel te vinden is, dus ik zou het zonde vinden om .net 3.5 alleen vanwege de updater als vereiste te hebben. Firefox ondersteuning is een must.

ThaStealth schreef op vrijdag 24 april 2009 @ 16:13:
main.exe start en runt de CheckUpdate() functie in de updater.exe.
Als CheckUpdate() true retourneert dan doe je (afhankelijk van user settings) de mogelijkheid bieden om de app te updaten. Als de gebruiker hiervoor kiest doe je hetvolgende:
-updater.exe starten
-main.exe sluiten

updater alles laten downloaden + updaten. (muv de updater.exe zelf, de update van updater.exe hernoem je naar updater.new oid). Nadat updater.exe klaar is laat je hem de main app runnen. Main app controleert of er een updater.new is met een bep signature, is dat zo, verwijder updater.exe en hernoem updater.new naar updater.exe. En voer vervolgens de checkupdate functie weer uit.

Dat is ook een optie. Het vervelende hieraan is dat de updater.exe gestart wordt voordat main.exe gesloten wordt. updater.exe moet dus gaan wachten totdat main.exe gesloten is, dat kan via een loopje dat wacht totdat het proces gesloten is. Ik vind dit echter een erg slordige oplossing, als main.exe om de een of ander reden niet sluit zoals verwacht heb je meteen een infinite loop in de updater te pakken.

Toch zal ik het in overweging nemen, aangezien dit een stuk makkelijker te implementeren valt.

Hoe zit dat eigenlijk met het updatebestand zelf? Ik had zelf in gedachten er een zipje van te maken met een xml-bestand met daarin bron- en bestemmingspaden. In dat xml-bestand kan ik dan bovendien pre- en post-installatie commando's e.d. aangeven. Vinden jullie het nodig om het update-bestand te beveiligen met een soort van wachtwoord/encryptie?

[ThaStealth]

Mocht het niet lukken om de main.exe te sluiten (dus na een bepaalde timeout) dan kun je em nog altijd forceren om te sluiten.

Ik weet niet in welke omgeving je werkt, en wat de verspreidingsmogelijkheden zijn (hi speed internet, 56k6 internet, etc). Maar je kan overwegen om de update zelf incrementeel te maken, dat de bestanden niet opnieuw gedownload worden maar alleen de veranderde delen in het bestand (dit is raadzaam als je langzaam internet gebruikt, als je hispeed internet hebt zou ik voor de gemakkelijke oplossing gaan en de veranderde bestanden opnieuw sturen).

Een (g)zip bestand is inderdaad het makkelijkste. Beveiligen met een wachtwoord is mogelijk, hoewel het een onnuttige functie is, zodra de update uitgevoerd is kun je eenvoudig achterhalen welke bestanden gewijzigd zijn. Als je bang bent dat mensen delen van het programma gaan rippen van je verspreidingsmedium kun je overwegen om een licentiesysteem te gebruiken zodat je de onderdelen wel kan gebruiken als je een bepaalde door de installer gegenereerd merkteken (registerkey bijv) heb.