Dove dovrebbe il mio programma win32 mantenere i suoi file?

Question

Le nostre applicazioni win32 (scritte in C++) esistono da oltre 10 anni e non sono state aggiornate per seguire le "buone pratiche" in termini di conservazione dei file. L'applicazione predefinita si installa nella cartella "C: \ AppName" e conserva i file generati dall'applicazione, i file di configurazione, i file scaricati e i documenti utente salvati nelle sottocartelle di quella cartella.

Presumibilmente, è "best practice" l'impostazione predefinita per l'installazione in "c: \ Programmi \ NomeApp" al giorno d'oggi. Ma se lo facciamo, dove dovremmo conservare il resto dei nostri file? A partire da Vista, la scrittura nella cartella dei file di programma è problematica e sembra che ci siano un milione di altri posti in cui è possibile inserire file diversi e io sono confuso.

C'è un riferimento da qualche parte per cosa va dove?

---

Modifica: Per espandere su questioni persone hanno chiesto finora:

---

ho familiarità con la funzione SHGetFolderPath, ma ci sono un sacco di opzioni che si possono ottenere da esso, e non riesco a trovare una risorsa che dice "Qui è esattamente ciò per cui ciascuna di queste opzioni è usata, e quando potresti volerlo usare".

Fino ad ora, abbiamo fatto la cosa "Tutti i file, inclusi i file utente salvati, sotto una cartella", ed è andata bene - ma non quando le persone vogliono installare l'app nella cartella Programmi. Per qualche ragione, la monkeying di virtualizzazione attorno a quello Vista non funziona per la nostra applicazione; se faremo comunque dei cambiamenti, potremmo fare uno sforzo per fare le cose nel modo "giusto", dal momento che non vogliamo doverlo cambiare di nuovo tra 12 mesi.

---

Ulteriore domanda:

---

Abbiamo includono alcuni documenti "campione" con la nostra applicazione, che aggiorniamo ogni tanto. È appropriato installarli in Documenti, se li sovrascriviamo ogni pochi mesi? O si presume che i miei documenti siano totalmente sicuri per gli utenti?

Se non è possibile installarli in Documenti, dove dovremmo inserirli in modo che gli utenti possano vederli facilmente?

Answer 1

Presumibilmente, è "buone pratiche" di default per l'installazione in "C: \ Programmi \ AppName"

Vicino, ma non del tutto. Gli utenti possono configurare il nome della cartella Programmi e potrebbero non avere nemmeno un'unità C :. Installare invece nella cartella variabile di ambiente %ProgramFiles%\AppName. Si noti che si dovrebbe presumere che si abbia accesso in lettura a questa cartella solo al termine dell'installazione.

Per i file di dati del programma in cui potrebbe essere necessario l'accesso in scrittura, utilizzare %AppData%\AppName.

Infine, sei sicuro che la tua sia l'unica app con quel nome? Se non ne sei sicuro al 100%, potresti voler includere anche il nome della tua azienda.

I meccanismi utilizzati per recuperare tali variabili variano in base alla piattaforma di programmazione. Normalmente si riduce al metodo Win32 SHGetFolderPath(), ma piattaforme diverse come Java o .Net possono fornire anche astrazioni più semplici.

Answer 2

Utilizzare la funzione Windows SHGetFolderPath() per ottenere le directory corrette.

Modifica: Per rispondere alla tua altra domanda, aggiunto nella modifica: dove mettere i file di esempio della tua applicazione dipende molto dal fatto che l'applicazione sia installata per un singolo utente o per tutti gli utenti, e la persona che installa l'applicazione può essere considerata come colui che la utilizza.

Se il programma deve essere utilizzato da più utenti su un sistema, la copia di materiale in "Documenti" non funzionerà - i file saranno accessibili solo per l'utente che installa l'applicazione. Peggio ancora, se l'unico utente della tua applicazione dovesse installare come amministratore, allora [s] non avrà accesso ai file. Pertanto, a meno che non si sia certi che ci sia un solo utente per la propria applicazione e che dispongano di autorizzazioni sufficienti per installare l'applicazione utilizzando il proprio account, non utilizzare "Documenti".

IMO è necessario installare i file di esempio nella directory identificata da CSIDL _ COMUNE _ APPDATA. Questo ti darà esattamente una copia per tutti gli utenti, e dato che vuoi che tutti gli utenti vedano i file di esempio inalterati, tutti gli utenti dovrebbero considerarli di sola lettura. In effetti, il tuo programma di installazione dovrebbe probabilmente renderli di sola lettura. L'apertura di uno degli esempi funzionerà per tutti gli utenti, ma non appena provano a salvare le loro modifiche l'applicazione dovrebbe rilevare che il file è di sola lettura e aprire la finestra di dialogo "Salva con nome", che punta a "Documenti" o adatto directory all'interno. Ciò manterrà anche tutte le modifiche dell'utente quando il programma di installazione aggiorna i file di esempio in seguito.

È ovviamente un po 'più difficile per gli utenti trovare i file di esempio. È possibile aggiungere un collegamento alla cartella degli esempi al gruppo del menu di avvio dell'applicazione, in modo che l'accesso ai file sia veloce e, naturalmente, è necessario documentare correttamente tutto.

Answer 3

Abbiamo un'app simile creata ~ 10 anni fa utilizzando MFC. La cosa più semplice da fare era creare una cartella direttamente da C: \ (ad esempio C: \ OurApp). Nessun file di installazione, nessuna autorizzazione speciale, nessuna modifica al registro, ecc. I client (e in particolare i loro amministratori di sistema) AMANO.

Un'altra considerazione: stai pianificando di cambiare improvvisamente la cartella di installazione per i client esistenti (supponendo che questo sia installato in molte posizioni)? Se qualcosa non è rotto, perché aggiustarlo?

Answer 4

C'è una struttura di directory in c: \ utenti per i dati orientati all'utente.

C'è documentazione per il porting di applicazioni da vecchi SO Windows a Vista.

Verificare http://www.innovateon.com e seguire i collegamenti a Vista. C'è una documentazione riguardante la certificazione che ha i dettagli su argomenti come questo.

Answer 5

dispiace non so la risposta corretta, ma ...

Avete un business case per voler fare questo? I tuoi clienti si lamentano che i file non vengono memorizzati dove si aspettano? Le tue applicazioni sono danneggiate in qualche modo perché archivi i file in posizioni non standard? In caso contrario, non vedo un motivo per spendere tempo e budget per ripristinare la strategia di archiviazione dei file solo per soddisfare la pratica "migliore".Se i tuoi programmi funzionano, allora IMHO dovresti lasciarli in pace e dedicare tempo e denaro a cose importanti.

Answer 6

Alcune linee guida sono contenute in questo articolo della Knowledge Base: How to write a Windows XP Application that stores user and application data in the correct location by using Visual C++. Inoltre, se cerchi MSDN per il programma logo di Windows, troverai la documentazione relativa a ciò che un'applicazione deve fare per essere veramente conforme.

SHGetKnownFolderPath può ottenere le directory necessarie. Se è necessaria la compatibilità all'indietro con XP e versioni precedenti, utilizzare il deprecato SHGetFolderPath

Detto questo, se si app è venuto con la documentazione che ha detto "tutto quello usato da questa applicazione è in questa directory" vorrei amore esso;)

Answer 7

Ci sono un sacco di variabili d'ambiente come:% USERPROFILE%,% HOMEPATH%,% APPDATA% tutti questi punti ad alcune directory specifiche dell'utente, dove puoi mettere i tuoi file specifici dell'utente.

Per la memorizzazione a livello di sistema è possibile utilizzare% ALLUSERSPROFILE%, ovvero il punto in cui inserire i file di dati di lettura/scrittura non specifici per qualsiasi utente.

Answer 8

Per i binari dell'applicazione, è possibile assumere che è possibile scrivere nella directory PROGRAM FILES (utilizzare la variabile di ambiente% ProgramFiles% per supportare installazioni diverse dalla versione inglese predefinita, ad esempio nelle installazioni tedesche ciò sarà c: \ Program di default). Wikipedia elenca le variabili più comuni. Un'altra opzione sono le funzioni SHGetFolderPath o più recente SHGetKnownFolderPath.

Per i dati utente, è necessario presumere che l'applicazione sia in esecuzione con diritti di accesso limitati e possa scrivere solo nella home directory dell'utente. Lo stesso vale per le voci di registro. Questo percorso dovrebbe probabilmente essere configurabile dall'utente, in quanto la directory home potrebbe effettivamente essere un server di rete e un utente potrebbe avere un secondo disco collegato per l'archiviazione dei dati. Per informazioni sulle linee guida attuali del file system (Vista), vedere this article.

Per quanto riguarda i plug-in, questo potrebbe essere più complicato. Le giuste pratiche offrono l'opzione di installazione solo per l'utente corrente e il posizionamento del plug-in nella directory utente o l'installazione per tutti gli utenti e il posizionamento dei file nella directory dei file di programma (ma ricordarsi di verificare l'autorizzazione e la richiesta di scrittura accesso elavated se necessario).