Ancora sui diritti in Vista/Seven

[Paolo Pini]

Chiedo scusa perchè so che l'argomento è stato già trattato sia qui che nel blog, ma purtoppo ancora non sono riuscito ancora ad avere una idea chiara sull'argomento e non riesco a trovare informazioni chiare nemmeno in rete, colpa anche della mia scarsa conoscenza delle problematiche dei diritti.

Allora, io verrei preparare una installazione che possa funzionare su XP/Vista/Seven, così composta:
Procedura VB6 SP3,
Cartelle di installazione della procedura su 'Program Files' alias 'Programmi', su Vista/Seven, fino a qui tutto ok.
Poi mi servono 2 cartelle per effettuare trasferimenti FTP dalla procedura, per cui lettura/scrittura (\FileTX e \FileRx)...
Un database Access in una cartella accessibile da tutti gli utenti...
E salvo scrivo un file temporaneo che utilizzerò per sapere se sono al primo avvio del programma per effettuare alcune configurazioni (\PrimoAvvio.flg) che poi eliminerò, per cui diritti di eliminazione.

ho provato a sistemare le cartelle ed i file nelle path indicate da CI:
$ALL_APPDATAPATH$
$COMMONPATH$
$APPODATAPATH$
Ma non mi trovo sempre i diritti limitati, non riesco a cancellare ad esempio il file PrimoAvvio.flg con un classico Kill dalla procedura.
Io ricavo i percorsi dal programma leggendo i CSIDL_* riportati dalla funzione SHGetFolderPath che corrispondono (+o-).
Dove *+£$@" devo installare i file per far si che ogni utente che si loggherà possa accedervi ed il programma possa avere tutti i diritti per leggere e scrivere.

Ringrazio in anticipo chiunque voglia darmi una dritta.

Ciao.

[Sergio Pappalardo]

Chiedo scusa perchè so che l'argomento è stato già trattato sia qui che nel blog, ma purtoppo ancora non sono riuscito ancora ad avere una idea chiara sull'argomento e non riesco a trovare informazioni chiare nemmeno in rete, colpa anche della mia scarsa conoscenza delle problematiche dei diritti.

Allora, io verrei preparare una installazione che possa funzionare su XP/Vista/Seven, così composta:
Procedura VB6 SP3,
Cartelle di installazione della procedura su 'Program Files' alias 'Programmi', su Vista/Seven, fino a qui tutto ok.
Poi mi servono 2 cartelle per effettuare trasferimenti FTP dalla procedura, per cui lettura/scrittura (\FileTX e \FileRx)...
Un database Access in una cartella accessibile da tutti gli utenti...
E salvo scrivo un file temporaneo che utilizzerò per sapere se sono al primo avvio del programma per effettuare alcune configurazioni (\PrimoAvvio.flg) che poi eliminerò, per cui diritti di eliminazione.

ho provato a sistemare le cartelle ed i file nelle path indicate da CI:
$ALL_APPDATAPATH$
$COMMONPATH$
$APPODATAPATH$
Ma non mi trovo sempre i diritti limitati, non riesco a cancellare ad esempio il file PrimoAvvio.flg con un classico Kill dalla procedura.
Io ricavo i percorsi dal programma leggendo i CSIDL_* riportati dalla funzione SHGetFolderPath che corrispondono (+o-).
Dove *+£$@" devo installare i file per far si che ogni utente che si loggherà possa accedervi ed il programma possa avere tutti i diritti per leggere e scrivere.

Ringrazio in anticipo chiunque voglia darmi una dritta.

Ciao.

Mi sembra che tu non debba fare niente da installazione, ma creare cartelle e file PrimoAvvio all'avvio del tuo programma.
Usa la cartella temporanea dell'utente se i file vanno cancellati alla chiusura sell'applicazione, oppure usa la cartella C:\Users\<nome utente>\AppData\Roaming se i dati devono persistere. In una sottocartella all'interno di questa cartella scriverei il file PrimoAvvio.flg.
Usa la cartella Users\Public se i file devono essere utilizzati da tutti gli utenti.

In tutti questi casi hai permessi di lettura/scrittura dall'utente standard, ossia non necessitano privilegi amministrativi.

[Paolo Pini]

Ti ringrazio per le indicazioni, provo subito.

Paolo Fiaschi

[Paolo Pini]

Ti ringrazio per le indicazioni, provo subito.

Paolo Fiaschi

Alla fine ho installato i dati (MDB,Cartelle di ricezione file ecc.) in una cartella nei documenti condivisi anche se non mi piace un granchè.
L'installazione invece và automaticamente su alcune macchine in Program Files su altre in Program Files (86) immagino perchè sono installazioni 64bit.
Comunque credo di aver risolto l'installazione grazie a questo ottimo programma!

Adesso sto cercando di creare un sistema automatico di update del programma; siccome il programma aggiorna periodicamente i suoi database tramite FTP pensavo di includere anche il nuovo eseguibile nell'invio, per poi scompattarlo e piazzarlo nella cartella di esecuzione con un FileCopy. Ovviamente su XP funziona ma non su Vista/Seven perchè non posso scrivere nella cartella di esecuzione programmi.
Immagino, ma non ho ancora provato, che dovrei inviare una nuova installazione di tutto il pacchetto e riavviarla in batch ma le dimensioni dell'installer sono proibitive e poi ha poco senso per 3Mb di eseguibile . Posso con CY scavalcare le policy di protezione creando un diciamo finto installer che copy soltanto l'eseguibile nella cartella di esecuzione?.

Grazie in anticipo e saluti

Paolo Fiaschi

[Sergio Pappalardo]

Adesso sto cercando di creare un sistema automatico di update del programma; siccome il programma aggiorna periodicamente i suoi database tramite FTP pensavo di includere anche il nuovo eseguibile nell'invio, per poi scompattarlo e piazzarlo nella cartella di esecuzione con un FileCopy. Ovviamente su XP funziona ma non su Vista/Seven perchè non posso scrivere nella cartella di esecuzione programmi.
Immagino, ma non ho ancora provato, che dovrei inviare una nuova installazione di tutto il pacchetto e riavviarla in batch ma le dimensioni dell'installer sono proibitive e poi ha poco senso per 3Mb di eseguibile . Posso con CY scavalcare le policy di protezione creando un diciamo finto installer che copy soltanto l'eseguibile nella cartella di esecuzione?.

Sì certo. Ma hai visto la possibilità di creare un pacchetto "aggiornamento" nel wizard di CIStudio? Fa proprio quello che dici, in più identifica automaticamente i file modificati (e solo quelli modificati!) se gli dai un file progetto sorgente da controllare, dopodichè sovrascriverà i file nella loro posizione originale per aggiornare il pacchetto preesistente. Vedi qui:
http://www.silvercybertech.com/italian/ ... l/0054.htm

o anche nel manuale in linea di CIS.

[Paolo Pini]

Adesso sto cercando di creare un sistema automatico di update del programma; siccome il programma aggiorna periodicamente i suoi database tramite FTP pensavo di includere anche il nuovo eseguibile nell'invio, per poi scompattarlo e piazzarlo nella cartella di esecuzione con un FileCopy. Ovviamente su XP funziona ma non su Vista/Seven perchè non posso scrivere nella cartella di esecuzione programmi.
Immagino, ma non ho ancora provato, che dovrei inviare una nuova installazione di tutto il pacchetto e riavviarla in batch ma le dimensioni dell'installer sono proibitive e poi ha poco senso per 3Mb di eseguibile . Posso con CY scavalcare le policy di protezione creando un diciamo finto installer che copy soltanto l'eseguibile nella cartella di esecuzione?.

Sì certo. Ma hai visto la possibilità di creare un pacchetto "aggiornamento" nel wizard di CIStudio? Fa proprio quello che dici, in più identifica automaticamente i file modificati (e solo quelli modificati!) se gli dai un file progetto sorgente da controllare, dopodichè sovrascriverà i file nella loro posizione originale per aggiornare il pacchetto preesistente. Vedi qui:
http://www.silvercybertech.com/italian/ ... l/0054.htm

o anche nel manuale in linea di CIS.

Si ho provato 'l'aggiornamento' però ho trovato qualche difficoltà per la gestione del progetto, sicuramente per la mia incompleta conoscenza del pacchetto.
Io ho creato un progetto con CI che ho chiamato 'Installazione' con tutto il mio pacchetto, poi un'altro progetto di CI che si chiama 'Aggiornamento' che contiene soltanto il .EXE del mio progetto, questo per poter aggiornare l'installazione con l'installer che posso inviare senza preoccuparmi dei diritti delle cartelle. Questo è provato e funzionante piuttosto bene (a parte che devo avviare il tutto con un VBScript ).
Il risultato è un 'installazione.exe" che invio sulle nuove installazioni ed un 'Aggiornamento.exe' che periodicamente mando quando ci sono variazioni soltanto sull'eseguibile.
Se creo invece un pacchetto di update con CI mi pare di aver capito che devo utilizzare lo stesso nome di progetto del pacchetto di installazione, cosa che mi ha un pò 'disorientato' nell'organizzazione logica del lavoro. Comunque dovrei aver risolto il tutto.
Settimana px spedisco 40 installazioni in giro per l'italia, fatemi gli auguri .

Grazie e saluti

[Sergio Pappalardo]

Si ho provato 'l'aggiornamento' però ho trovato qualche difficoltà per la gestione del progetto, sicuramente per la mia incompleta conoscenza del pacchetto.
Io ho creato un progetto con CI che ho chiamato 'Installazione' con tutto il mio pacchetto, poi un'altro progetto di CI che si chiama 'Aggiornamento' che contiene soltanto il .EXE del mio progetto, questo per poter aggiornare l'installazione con l'installer che posso inviare senza preoccuparmi dei diritti delle cartelle. Questo è provato e funzionante piuttosto bene (a parte che devo avviare il tutto con un VBScript ).

Perchè con VBScript?

Il risultato è un 'installazione.exe" che invio sulle nuove installazioni ed un 'Aggiornamento.exe' che periodicamente mando quando ci sono variazioni soltanto sull'eseguibile.
Se creo invece un pacchetto di update con CI mi pare di aver capito che devo utilizzare lo stesso nome di progetto del pacchetto di installazione, cosa che mi ha un pò 'disorientato' nell'organizzazione logica del lavoro. Comunque dovrei aver risolto il tutto.

Se non crei il pacchetto aggiornamento con lo stesso nome e con il flag "aggiornamento" impostato al passo 1 (oppure più semplicemente usi la "Composizione guidata pacchetto aggiornamento" che fa tutto lei, ti trova anche solo i file modificati rispetto al pacchetto originario che gli dai in input) è come creare un pacchetto normale!

Tu puoi chiamare il tuo file di progetto "Aggiornamento <nome applicazione>", mentre il progetto originario "<nome applicazione> full", ma il nome dell'applicazione al passo 1 nel pacchetto aggiornamento dev'essere necessariamente identico a quello del progetto "full", altrimenti CyberInstaller non può controllare se il pacchetto originario è già installato e comportarsi di conseguenza (io seguo questa logica).

Settimana px spedisco 40 installazioni in giro per l'italia, fatemi gli auguri .

Grazie e saluti

Allora terrò le dita incrociate per te , ma sono sicuro che se usi CyberInstaller nel modo giusto non avrai problemi!