[c#] Update structuur in de applicatie

[Verwijderd]

Momenteel ben ik bezig met onderzoek naar hoe we een applicatie het beste de functionaliteit Automatische Updates kunnen geven.

Ik heb al wat onderzocht, kwam uit op ClickOnce of zelf iets maken.
Hieruit heb ik de keuze gemaakt zelf iets te maken aangezien we er genoeg tijd in kunnen stoppen en het op een bepaalde manier fijner voelt zelf de controle te hebben over dat soort zaken.

Afgezien van deze keus kwam ik op het volgende probleem:
Hoe richt ik mijn applicatie in om updates veilig, stabiel, flexibel en snel te laten zijn in c#.

Wat ik online tegenkwam was de oplossing om alles in aparte projecten te ontwikkelen, de onderdelen allemaal inladen in één groot project dat uiteindelijk dus de libraries van de andere aanspreekt. Op die manier update je elke keer één of meerdere libraries, die je dan erg klein moet houden om de snelheid en flexibiliteit te behouden. Dit lijkt mij echter ook juist weer leiden tot een grotere omvang omdat het gewoon niet te vermijden is dat ook het hoofd project het weer anders moet gaan benaderen (ook al zou je die weer opsplitsen blijf je hetzelfde houden alleen in een ander bestand).

Nu was mijn vraag wat hier een beetje de best practice in is. Uiteraard mag het qua ontwikkelen gerust iets intensiever zijn, zolang het maar een veilige, stabiele, flexibele en snelle manier is.

[Woy]

Verwijderd schreef op maandag 07 februari 2011 @ 17:35:
Ik heb al wat onderzocht, kwam uit op ClickOnce of zelf iets maken.
Hieruit heb ik de keuze gemaakt zelf iets te maken aangezien we er genoeg tijd in kunnen stoppen en het op een bepaalde manier fijner voelt zelf de controle te hebben over dat soort zaken.

Het lijkt me dat je een beetje last hebt van het Wikipedia: Not Invented Here syndroom.

Wat is de reden dat ClickOnce niet voldoet aan de eisen voor jullie bedrijf?

Microsoft heeft overigens in het verleden een Application Update Block gemaakt, dus daar zou je eens naar kunnen kijken.

Maar feitelijk is het heel erg eenvoudig
* Kijken of er een nieuwere versie is ( Eventueel per component )
* Nieuwere versie downloaden
* Backup maken origineel
* Bestanden overschrijven
* Programma opnieuw opstarten

Het probleem is dat je niet zomaar je eigen programma bestanden kan overschrijven als je programma nog runt.

[Verwijderd]

Ik was niet van plan om dingen opnieuw te schrijven als het niet nodig is hoor, zolang het ons maar de dingen biedt die we nodig hebben.

Als ik bekijk wat we nodig hebben is ClickOnce qua acties redelijk goed, het haalt inderdaad het lijstje van punten die nodig zijn met gemak. Probleem met ClickOnce zijn echter dat het browser gebonden is zover ik weet, momenteel draait het onder IE en ik dacht een plugin onder Firefox alhoewel die niet stabiel schijnt te zijn. Wat wij willen bieden is stabiliteit onder andere voorwaarden zoals mensen zonder IE.

Van Application Update Block weet ik in principe dat ze als het goed is de support daarvan hebben laten vallen, als ik op msdn kijk zie ik artikelen uit 2005, en de melding retired content. Overigens heeft het qua functionaliteit wel meer weg van wat wij willen dat ClickOnce dus in ieder geval bedankt voor de duw in die richting om er nog eens dieper naar te kijken!

Wat je als update proces kan doen is in principe jouw lijstje:

* Kijken of er een nieuwere versie is ( Eventueel per component )
* Update.exe oid runnen
* Nieuwere versie downloaden
* Backup maken origineel
* Bestanden overschrijven
* Updater.exe sluiten
* Programma opnieuw opstarten

Waarbij ik dus de updater.exe toevoeg om ervoor te zorgen dat je het eigen programma kan overschrijven. Ook zal de updater.exe ervoor zorgen dat de applicatie alle afhankelijkheden afsluit (door een geforceerde veilige afsluiting), denk hierbij aan locking en dergelijke.

Waar het mij ook meer om gaat is hoe je de applicatie zelf opbouwt, hoe je ervoor zorgt dat het in delen is opgebouwd maar nog wel overzichtelijk qua ontwikkelen en dat het niet zo'n gigantische rommel met dll's wordt dat je om 1 kleine update meteen 10 dll's moet updaten.

[ Voor 11% gewijzigd door Verwijderd op 07-02-2011 18:13 . Reden: Application Update Block ]

[CodeIT]

Wij hebben de updater.exe ook op de download server staan zodat we die ook snel kunnen updaten.
Denk ook goed na over de beveiliging. We hebben de geupdate bestanden (hashes) gesigned met een private key.
Verder kan bij ons de updater ook 'syncen' door alleen de gewijzigde bestanden te downloaden. Hiervoor vergelijkt de applicatie de hashes van zijn eigen bestanden met die van die server. De hashes van de server worden, na een download, opgeslagen zodat deze niet iedere keer opnieuw hoeven worden berekend.

[Verwijderd]

CodeIT schreef op maandag 07 februari 2011 @ 18:21:
Wij hebben de updater.exe ook op de download server staan zodat we die ook snel kunnen updaten.
Denk ook goed na over de beveiliging. We hebben de geupdate bestanden (hashes) gesigned met een private key.
Verder kan bij ons de updater ook 'syncen' door alleen de gewijzigde bestanden te downloaden. Hiervoor vergelijkt de applicatie de hashes van zijn eigen bestanden met die van die server. De hashes van de server worden, na een download, opgeslagen zodat deze niet iedere keer opnieuw hoeven worden berekend.

Hoe zorg je dan voor een veilige updater.exe update? Overigens is het werken van hashes inderdaad erg handig, simpele check voor alle bestanden.

Hoe hebben jullie de applicatie in c# zelf opgebouwd om zo updatable mogelijk te zijn? Dat is namelijk het punt waar ik niet echt online een eenduidig best practice kan vinden.

[YopY]

Verwijderd schreef op maandag 07 februari 2011 @ 19:30:
Hoe hebben jullie de applicatie in c# zelf opgebouwd om zo updatable mogelijk te zijn? Dat is namelijk het punt waar ik niet echt online een eenduidig best practice kan vinden.

Dat komt waarschijnlijk omdat die er niet is. Een goeie applicatie bouw je van nature al op in componenten, al dan niet los van elkaar. Het enige wat een updater doet is die componenten (op whatever het uiteindelijke bestandsformaat wordt) vervangen, en of je dat nu doet door je programma in 10.000 componenten of in twee componenten (een loader / updater en de applicatie zelf) maakt dan geen fluit uit.

Ik heb totaal geen verstand van C# of automatische updates of wat dan ook, maar ik zou het op één van de volgende methodes doen:

1. Ipv het programma zelf start de gebruiker altijd een loader op, die controleert op een update en, indien nodig, deze update uitvoert door de programmabestanden te overschrijven.
2. Alternatief: Het programma zelf controleert op updates, downloadt de nieuwe bestanden, en bij het initiëren van de updateprocedure start het een updater aan terwijl het zichzelf afsluit. De updater kopieert de bestanden.

In bovenstaand zijn er maar twee componenten daadwerkelijk gedefiniëerd, het programma en de updater. Hoe het programma zelf eruit ziet is totaal niet belangrijk, de enige voorwaarde is dat de bestanden overschrijfbaar moeten zijn door een updater, wat een behoorlijk triviaal programma is dat niets anders doet dan het rijtje met zaken dat hierboven opgenoemd is - backup, update, herstart, bam.

[Verwijderd]

YopY schreef op maandag 07 februari 2011 @ 19:44:
[...]
Dat komt waarschijnlijk omdat die er niet is. Een goeie applicatie bouw je van nature al op in componenten, al dan niet los van elkaar. Het enige wat een updater doet is die componenten (op whatever het uiteindelijke bestandsformaat wordt) vervangen, en of je dat nu doet door je programma in 10.000 componenten of in twee componenten (een loader / updater en de applicatie zelf) maakt dan geen fluit uit.

Tsjah dat zou natuurlijk kunnen, dat er gewoon geen één is. Maar het lijkt me logisch dat er ergens gewoon een optimale mogelijkheid zit toch? Desnoods een formule met het gemiddelde aantal externe links tussen je componenten gecombineerd met de optimale bestands-deel factor alhoewel ik er zelf totaal geen gooi naar kan doen.

Ik ben er, i.c.m. jullie reacties overigens wel al uit hoe ik het ga doen, inderdaad door het programma te updaten ongeacht wat je update (wel of geen componenten als aparte files), en het d.m.v. een standaard loader te checken die een updater.exe aanroept die het proces verder afhandelt.

Hoe ik updater.exe dan zelf update heb ik nog mijn twijfels over, ik zou natuurlijk een soort functie in de loader in kunnen bouwen die ervoor zorgt dat newupdater.exe hernoemt wordt naar updater.exe en je op die manier altijd je updater update als deze de run ervoor iets heeft gedownload.
Overigens niet een manier om erg trots op te zijn qua schoonheid.

[BertS]

Je kunt het ook anders doen:
1. Programma bij het opstarten versie laten controleren in (bijv.) een xml-bestandje dat op een webserver staat;
2. Indien nieuwere versie: installer downloaden, installer silent runnen, programma afsluiten direct na starten van installer, programma laten starten aan het einde van de install (door installer).

Dit kan al uitstekend met bijv. Inno Setup.

[Verwijderd]

BertS schreef op maandag 07 februari 2011 @ 20:59:
Je kunt het ook anders doen:
1. Programma bij het opstarten versie laten controleren in (bijv.) een xml-bestandje dat op een webserver staat;
2. Indien nieuwere versie: installer downloaden, installer silent runnen, programma afsluiten direct na starten van installer, programma laten starten aan het einde van de install (door installer).

Dit kan al uitstekend met bijv. Inno Setup.

Dan zou je het hele updater probleem omzeilen, je moet gewoon een installer maken die de benodigde acties voor zijn rekening neemt. Klinkt in principe erg handig. Heb ook even gezocht online en zag dat het zelfs de mogelijkheid heeft een database aan te passen, wat in ons geval ideaal is. Ik zal dan wel die scripting taal moeten leren maar dat is in principe geen groot probleem.
Het klinkt in ieder geval als de een van de nettere methodes so far, je updater is er niet zolang er maar een check is die de check uitvoert en een download mogelijkheid biedt!

[BertS]

Wel opletten dat je de installer verwijdert na het uitvoeren, dat is toch een beetje een updater.
Voor het aanpassen van database e.d.: je kunt ook in je installer een kleine db-updater includen die tijdens het uitvoeren van de installer wordt uitgevoerd.
De reden dat ik een installer noem is dat die ervoor gemaakt zijn om bestanden bij te werken, en dat het zelf schrijven van een 'updater' neer zal komen op een selfmade installer. Wiel opnieuw uitvinden dus, wat niet nodig is.

[MLM]

Er zijn 1001 updaters te vinden op het internet, vast ook C#. Waarom zou je zelf iets schrijven met alle kansen van bugs die dan volgen.

Er zijn ook genoeg (al dan niet) commerciele installer-makers die ook updates kunnen maken. Vanuit je applicatie een http://jouwdomein.com/upd...t=$geinstalleerde_versie$ request doen die de updater download (als er een update is) en dan die updater starten gaat ook prima werken en ongeveer 10 regels code kosten als bij de start van je applicatie + een bestandje op de webserver dat intelligent de laatste update aanbied

[Hydra]

Als je perse het wiel opnieuw uit wil vinden:

De simpelste methode is om je daadwerkelijke applicatie in een library te zetten (gewoon een .Net DLL dus) en een erg simpele launcher mee te leveren. Het enige wat die launcher doet is (A) checken of er een InstallerPackage.dll (oid) in de root staat, zo ja dan start hij die app, zo nee dan start hij de main applicatie (AppPackage.dll oid). De main app is verantwoordelijk voor het checken van updates. Zodra deze er zijn download hij deze en zet hij deze klaar in de vorm van die InstallerPackage.dll. De applicatie laat aan de launcher weten dat hij opnieuw moet starten als er een update is, het de launcher herstart dan, en voert de installarpackage uit.

Je kunt dit verder zo simpel of fancy maken als je wil, met SHA-1 hashes e.d. voor veiligheid. Maar dit is verder best wel triviaal.