Newsgroup: it.comp.programmare
Titolo: autoaggiornamento sotto windows

Come fareste voi ad impostare una funzione di autoaggiornamento di un 
programma eseguibile sotto windows?
Mi spiego: il programma, un eseguibile con eventuali files di appoggio, 
per verificare se vi sia disponibile un aggiornamento effettua una 
interrogazione ad un server web, e, se e' disponibile un aggiornamento, 
lo scarica e lo installa sopra di se'.
Il problema e' che in ambiente windows, un eseguibile non puo' 
cancellare o sovrascrivere se stesso.
Come si potrebbe gestire la cosa?
Ho pensato ad un secondo eseguibile, presente nella stessa directory, al 
quale passare la palla per sovrascrivere l'eseguibile principale con 
l'aggiornamento.
Ma se fosse proprio l'eseguibile di appoggio a necessitare aggiornamento?
Accetto idee, suggerimenti, consigli.

Come si potrebbe gestire la cosa?
Il metodo che ho sempre seguito io è quello di avere un launcher:
un'applicazione che lancia l'eseguibile vero e proprio e che fa tutti
i controlli sull'aggiornamento. L'aggiornamento vero e proprio lo
distribuisco come setup, in modo da poter aggiornare il launcher
stesso.

 stesso.
Non credo di avere capito: stai dicendo che nonostante il lanciatore che 
fa i controlli, distribuisci comunque un setup che l'utente deve 
installarsi da solo?

installarsi da solo?
Quando il launcher trova che c'è un aggiornamento, lo comunica
all'utente il quale risponde se vuole scaricarlo (e quasi sempre
*deve* scaricarlo). Una volta scaricato, il launcher, prima di uscire,
invoca il setup. L'utente conferma i passi canonici e la patch viene
installata. Non si tratta di "installarselo da solo", ma di fare
un'installazione standard. Nel caso di un server, si può procedere
analogamente, a meno delle conferme dell'utente: si distribuisce
un'installazione della patch che può modificare non solo l'eseguibile
specifico, ma fare varie operazioni (database compreso). Installazione
lanciata in automatico dal launcher.

 
Quindi anche secondo te, un programma parallelo e' imprescindibile per 
realizzare un autoaggiornamento, sia nel caso in cui il programma venga 
lanciato spesso, sia nel caso in cui il programma giri in continuazione.
Se non arrivano altri pareri con soluzioni diverse, procedero' in questa 
direzione.

Roberto Montaruli ha scritto:

Secondo me non e' affatto necessario che ci siano continuamente in 
esecuzione due processi.
Il programma di aggiornamento puo' essere lanciato dal programma 
principale solo quando si effettua un aggiornamento del programma 
principale.
Il controllo della disponibilita' di un aggiornamento e l'aggiornameto 
del programma di aggiornamento lo possono fare il programma principale 
stesso.
Se tutti per ogni applicazione avessimo un processo di aggiornamento, su 
un computer che ha installato 100 applicazioni partirebbero 100 processi 
all'avvio, e questo mi sembra un bello spreco di risorse.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

all'avvio, e questo mi sembra un bello spreco di risorse.
Non ho capito che intendi. Che c'entrano i 100 processi all'avvio?
Se un sistema ha 100 applicazioni installate che vanno aggiornate,
avrà 100 applicazioni "guardian" che a tempi regolari vengono eseguite
per controllare eventuali aggiornamenti. Non capisco dove sia il
problema.

 problema.
Effettivamente non e' un problema: il processo guardian mica gira sempre.
Dividiamo i programmi in due categorie: le applicazioni desktop che 
vengono lanciate spesso (e queste possono verificare la presenza di un 
aggiornamento solo una volta all'avvio), e le applicazioni server che 
girano sempre su una macchina sempre accesa (che possono verificare la 
presenza di un aggiornamento ogni tot ore).
Del resto la verifica della presenza di un aggiornamento e' una semplice 
HTTP/GET ad un server prestabilito.
Poi, se si desidera effettuare l'aggiornamento vero e proprio, e' ovvio 
che questa operazione richiedera' un po' di tempo e risorse, dovendosi 
fare il download prima e il setup dopo, ma di queste 100 applicazioni 
che girano, mica tutte scaricheranno l'aggiornamento contemporaneamente, no?

che girano, mica tutte scaricheranno l'aggiornamento contemporaneamente, no?
Ma questo, anche se fosse, è un problema distinto. Diventa un problema
di performance, cioè come schedulare i vari agent di aggiornamento in
modo che non si accavallino o che riducano al minimo il consumo di
risorse.

 problema.
Queste applicazioni "guardian", mi pare che possono funzionare in due 
modi possibili:
1) Sono sempre in esecuzione e a intervalli regolari fanno un controllo. 
Questa e' la tecnica di Java e di RealPlayer.
2) Sono lanciate da uno scheduler a intervalli regolari. Quando partono 
fanno un controllo e terminano subito.
Nel primo caso, se si hanno 100 programmi, si hanno 100 processi.
Nel secondo caso, anche avendo 100 programmi, si ha un solo processo, 
che puo' essere lo scheduler di sistema.
Penso sia preferibile la seconda soluzione, soprattutto dato che un 
controllo del genere non deve essere eseguito ogni 24 millisecondi ma 
ogni 24 ore. Tutavia pare che non tutti la prediligano.


Andrea Laforgia ha scritto:

Qui entriamo in un altro ambito: questi 100 programmi dovrebbero potersi 
parlare tra di loro e se non sono programmi di uno stesso pacchetto, col 
cavolo che si parlano.
Pero' alla luce di questo, sarebbe cosa furba, nella configurazione del 
proprio programma, prevedere oltre all'autoupdate anche un orario in cui 
schedulare il controllo, cosi' se gli altri 99 si accavallano tutti al 
boot per scaricarsi gli aggiornamenti, il nostro invece e' configurato 
per fare la verifica (e l'autoupdate) solo in determinati momenti.
Una cosa alla volta comunque.

all'avvio del computer ne' per controllare se ci sono aggiornamenti.
Un'applicazione non può incaricarsi anche di tutto il lavoro relativo
al suo aggiornamento. E' bene lasciarle fare i suoi compiti specifici
e basta. La responsabilità dell'aggiornamento può essere demandata a
una seconda applicazione che parte, controlla, e nel migliore dei casi
termina.

cavolo che si parlano.
Temo non abbia molto senso discutere tirando fuori numeri a casaccio.
Meglio attenersi alle esigenze reali.

 wrote in
news:17h4j.12962$
r62....@tornado.fastwebnet.it
: 

Oltre alle idee suggerite da Andrea che sono secondo me 
correttissime, ti segnalo un paio di aspetti da considerare:
- notifica all'utente che stai per collegarti all'esterno con, al 
limite, la possibilità di disabilitare le notifiche successive. 
Questo ti può evitare problemi con utenti che scoprono che il tuo 
software si collega e possono pensare che lo faccia per motivi non 
leciti e con utenti che usano personal firewall o strumenti simili e 
che sapranno così gestire le richieste del sofware in oggetto 
("l'applicazione pippo vuole collegarsi a internet") senza farsi 
prendere dal panico.
- considera la possibilità, se già le tue funzioni non lo fanno, di 
gestire il collegamento per la verifica e il download in HTTP 
passando anche per un eventuale proxy. Altrimenti rischi che il tuo 
software non funzioni correttamente su una rete aziendale 
"blindata" a modo.
Evita protocolli non standard con porte TCP/IP scelte a caso o 
collegamenti attivati dal server al client che non funzionano 
passando anche solo per un banale router domestico, a meno di non 
obbligare il cliente a configurare componenti di cui, magari, non 
conosce nemmeno l'esistenza.
- considera, se non è troppo complesso, la possibilità che il tuo 
"launcher" possa ripristinare la penultima versione, in caso di 
problemi in fase di aggiornamento.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 aggiornamenti. 
Concordo sul fatto che troppi programmi hanno un comportamento 
"invasivo" (sul mio PC, ad esempio, Acrobat Reader non si aggiorna e 
il suo downloader resta sistematicamente piantato).
L'unico problema che vedo nel far scaricare gli aggiornamenti 
all'applicazione stessa è che, in caso di aggiornamento fallito, non 
c'è verso di ripristinare il funzionamento dell'applicazione perchè 
non è possibile fare il download della versione che magari sistema 
proprio il problema che sta la sta bloccando in quella specifica 
situazione!
Usare un'applicazione di verifica degli aggionamenti schedulata 
abbastanza semplice consente di poter sempre fare un download "di 
emergenza" (ed è più semplice dire all'utente di lanciare qualcosa dal 
menu di avvio piuttosto che farlo andare sul nostro sito, trovare il 
download corretto, scaricarlo e lanciarlo).
Inoltre, se l'applicazione è abbastanza parametrizzabile, potrebbe 
essere usata per aggiornare tutte le applicazioni della stessa azienda 
(ovvio che il discorso vale anche per una DLL esterna richiamata 
dall'applicazione che però dovrebbe essere mantenuta allo stesso 
livello di aggiornamento in tutte le applicazioni).


 essere usata per aggiornare tutte le applicazioni della stessa azienda 
Io questo lo dò per scontato. Ovviamente quando si pensa a un sistema del
genere, non lo si taglia su misura di una specifica applicazione.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 problemi in fase di aggiornamento.
Questa e' una cosa da approfondire.
Sulla carta dovrebbe essere fattibile.
Bisogna vedere coi files di lavoro se viene modificato qualcosa.
L'importante e' mettere sul programma un meccanismo ben oliato di
autoaggiornamento. Il resto verra' aggiunto con gli aggiornamenti
successivi.


 situazione!
L'aggiornamento e' costuito dalle seguenti fasi:
1) Verifica della disponibilita' di un aggiornamento.
2) Eventuale richiesta di conferma all'utente per scaricare l'aggiornamento.
3) Scaricamento dell'aggiornamento in un file temporaneo.
4) Verifica della correttezza del file scaricato.
5) Eventuale richiesta di conferma all'utente per effettuare 
l'aggiornamento (alternativo al punto 2).
6) Sostituzione del programma con la versione aggiornata.
7) Verifica della corretta sostituzione del programma.
8) Cancellazione del file temporaneo scaricato.
C'e' qualcuno che sostiene che tutti questi punti dovrebbero essere 
effettuati dal programma ausiliario.
Io, invece, ritengo preferibile che almeno il punto 1 sia effettuato dal 
programma principale stesso, sebbene sicuramente i punti 6, 7, e 8 
devono essere effettuati dal programma ausiliario. I punti 2, 3, 4, e 5 
potrrebbero essere effettuati da entrambe le parti.
I vantaggi di lasciare il punto 1 all'applicazione principale sono:
1) Non si scomoda lo scheduler di sistema con un compito che interessa 
una sola applicazione.
2) L'applicazione non viene inutilmente aggiornata se non viene usata.
3) Si puo' scoprire quanti stanno usando l'applicazione.
Per avere un programma ausiliario di aggiornamento completamente 
autonomo, basta lasciargli i punti 2, 3, 4, e 5.


3) Si puo' scoprire quanti stanno usando l'applicazione.
Questa non l'ho capita.

 Questa non l'ho capita.
Supponendo che tu abbia un controllo sul server che viene interrogato 
dalle varie applicazioni sparse per il mondo per sapere se ci sono 
aggiornamenti, puoi ottenere l'informazione di quante applicazioni del 
programma stiano girando, ed eventualmente associarle ad un indirizzo IP.



Non mi sono spiegato. Non ho capito in che senso il punto 3) sarebbe
un vantaggio dovuto all'affidare il controllo all'applicazione stessa,
rispetto a delegarlo ad un agente esterno.
Anche se il controllo sull'aggiornamento fosse affidato ad un agente
esterno avresti la possibilità di tenere traccia di questa
informazione. L'applicazione + il suo agent di aggiornamento
costituiscono un unico sistema. Tutto ciò che si può fare con un'unica
applicazione è fattibile con questo unico sistema. Che poi il sistema
consista di due processi separati è un mero dettaglio tecnico.

 Questa non l'ho capita.
Per ottenere tale risultato, l'agente dovrebbe verificare se 
l'applicazione e' in esecuzione e non fare niente in caso negativo.
L'applicazione stessa ha la vita semplificata: sa gia' di essere in 
esecuzione.


esecuzione.
Mi sa che stiamo parlando di mele e di patate.

 rispetto a delegarlo ad un agente esterno.
Io non credo che si possa parlare di vantaggio o svantaggio in senso
assoluto.
Dipende essenzialmente da che cosa fa l'applicazione.
Se per esempio l'applicazione fosse un browser o un qualcosa che si
collega alla rete di suo per eseguire la funzione principale, in questo
caso una interrogazione ad un indirizzo per verificare se c'e' un
aggiornamento dovrebbe essere meno dispendioso farlo fare all'applicazione.
In altri casi puo' essere piu' conveniente che sia il lanciatore
dell'applicazione ad effettuare il test.
Certo che se si intende distribuire diversi pacchetti separati di cose
diverse, una unica entita' preposta al controllo della disponibilita' di
aggiornamenti sarebbe la cosa piu' pratica, ma io sconsiglierei questa
strada: non si puo' mai sapere che cosa ci riserva il futuro, programmi
nuovi, programmi abbandonati, programmi ceduti a terzi...
Meglio che ogni programma sia autonomo nella ricerca e nell'installazione
dei propri aggiornamenti.
Una trascurabile percentuale di risorse in piu' nel caso in cui si
posseggano piu' pacchetti dello stesso produttore, in cambio di una
immensa comodita'.


 wrote in
news:iH_4j.15352$
r62...@tornado.fastwebnet.it
: 

Fai bene attenzione a come usi questo tipo di "tracciamento" perchè in 
alcuni casi potrebbe rappresentare una volazione della privacy.
L'idea di contollare chi e quando usa l'applicazione può essere 
"attraente" (per marketing o per controllare le copie pirata), ma se 
ti presenti dalla finanza con un log del genere rischi più tu di un 
ipotetico "copiatore", temo.


 3) Si puo' scoprire quanti stanno usando l'applicazione.
In realtà l'updater esterno non impedisce questo tipo di controllo. 
Tieni presente che, come ti dicevo prima, questo tipo di logging lo 
puoi fare per tuoi fini "statistici", ma devi stare attento a non 
divulgare dati o collezionare dati personali.
Credo che anche l'idea di lasciare le funzioni di aggiornamento 
dentro l'applicazione possa avere le sue motivazioni.
Resto convinto che l'utilizzo di un updater esterno sia la soluzione 
più robusta. Pensa al caso in cui, per qualche motivo, una DLL della 
tua applicazione non si carica su una determinata versione del S.O. 
(magari hai usato una funzione prevista solo nel SP3412 di XP e 
l'utente non l'ha installato, ad esempio, oppure l'utente ha 
installato una diversa versione di qualche libreria che la tua 
applicazione utilizza). L'updater ti consentirebbe di far aggiornare 
l'applicazione automaticamente, al limite "forzando" un'update 
immediato (ovviamente dopo aver capito il problema e averlo 
sistemato!), nell'altro caso dovresti spedire i file da aggiornare e 
far fare l'aggiornamento "manuale" all'utente.
