Quando - e perché - è necessario memorizzare i dati nel registro di Windows?

Come sviluppatore, gli strumenti che memorizzano la configurazione / le opzioni nel registro sono la rovina della mia vita. Non riesco facilmente a rintracciare le modifiche a queste opzioni, non riesco facilmente a portarle da una macchina all'altra e tutto ciò mi fa davvero desiderare i bei vecchi tempi dei file .INI ...

Quando scrivo le mie applicazioni, cosa dovrei scegliere di inserire nel registro piuttosto che nei file di configurazione vecchio stile, e perché?

• Inizialmente la configurazione (WIN3) era archiviata nel file WIN.INI nella directory di Windows.
• Problema: WIN.INI è diventato troppo grande.
• Soluzione (Win31): singoli file INI nella stessa directory del programma.
• Problema: quel programma può essere installato su una rete e condiviso da molte persone.
• Soluzione (Win311): singoli file INI nella directory Window dell'utente.
• Problema: molte persone possono condividere una cartella di Windows, che dovrebbe comunque essere di sola lettura.
• Soluzione (Win95): registro con sezioni separate per ciascun utente.
• Problema: il registro è diventato troppo grande.
• Soluzione (WinXP): grandi blocchi di dati individuali spostati nella cartella Dati applicazioni dell'utente.
• Problema: buono per grandi quantità di dati, ma piuttosto complesso per piccole quantità.
• Soluzione (.NET): piccole quantità di dati fissi di sola lettura archiviati in file .config (Xml) nella stessa cartella dell'applicazione, con API per leggerlo. (La lettura / scrittura o i dati specifici dell'utente rimangono nel registro)

Venendo a questo, sia dal punto di vista dell'utente che dal punto di vista dei programmatori, dovrei dire che in realtà non esiste un buon esodo per mettere qualcosa nel registro a meno che non si tratti di associazioni di file o impostazioni specifiche della macchina.

Vengo dalla scuola di pensiero che dice che un programma dovrebbe essere eseguibile da qualsiasi luogo sia installato, che l'installazione dovrebbe essere completamente mobile all'interno di una macchina, o anche su un'altra macchina e non influire sul suo funzionamento.

Eventuali opzioni configurabili, dll richieste ecc., Se non condivise, devono risiedere in una sottodirectory della directory di installazione, in modo che l'intera installazione venga facilmente spostata.

Uso molti programmi di utilità più piccoli come i programmi, quindi se non può essere installato su una chiavetta USB e collegato a un'altra macchina e appena eseguito, non fa per me.

Politica di Microsoft:

• Prima di Windows 95, abbiamo usato i file INI per i dati dell'applicazione.
• Nell'era di Windows 95 - XP, abbiamo usato il registro.
• Da Windows Vista, usiamo i file ini anche se ora sono basati su XML.

Il registro dipende dalla macchina. Non mi è mai piaciuto perché sta rallentando ed è quasi impossibile trovare ciò di cui hai bisogno. Ecco perché mi piacciono i file ini semplici o altri file di impostazione. Sai dove si trovano (cartella dell'applicazione o cartella utente) in modo che siano facilmente trasportabili e leggibili.

Quando - Sei costretto a farlo a causa dell'integrazione legacy o perché l'amministratore di sistema del tuo cliente dice "deve essere così" o perché stai sviluppando in un linguaggio più vecchio che rende più difficile usare XML.

Perché : principalmente perché il registro non è portatile come la copia di un file di configurazione che si trova accanto all'applicazione (e si chiama quasi lo stesso).

Se stai usando .Net2 + hai i file App.Config e User.Config e non hai bisogno di registrare le DLL nel registro quindi stai lontano da esso.

I file di configurazione hanno i loro problemi (vedi sotto), ma questi possono essere codificati e puoi modificare la tua architettura.

• Problema: le applicazioni richiedono impostazioni configurabili.
• Soluzione: archiviare le impostazioni in un file (WIN.INI) nella cartella Windows: utilizzare le intestazioni di sezione per raggruppare i dati (Win3.0).
• Problema: il file WIN.INI è diventato troppo grande (ed è diventato disordinato).
• Soluzione: memorizzare le impostazioni nei file INI nella stessa cartella dell'applicazione (Win3.1).
• Problema: sono necessarie impostazioni specifiche dell'utente.
• Soluzione: memorizzare le impostazioni utente in file INI specifici dell'utente nella directory Window dell'utente (Win3.11) o sezioni specifiche dell'utente nel file INI dell'applicazione.
• Problema: sicurezza: alcune impostazioni dell'applicazione devono essere di sola lettura.
• Soluzione: Registro di sicurezza con sezioni specifiche per l'utente e a livello di macchina (Win95).
• Problema: il registro è diventato troppo grande.
• Soluzione: il registro specifico dell'utente è stato spostato in user.dat nella cartella "Dati applicazioni" dell'utente e caricato solo all'accesso (WinNT).
• Problema: in ambienti aziendali di grandi dimensioni accedete a più macchine e dovete impostare OGNI UNO.
• Soluzione: distinguere tra i profili locali (Impostazioni locali) e quelli in roaming (Dati applicazioni) (WinXP).
• Problema: impossibile eseguire xcopy per distribuire o spostare applicazioni come il resto di .Net.
• Soluzione: il file XML APP.CONFIG nella stessa cartella dell'applicazione -, facile da leggere, facile da manipolare, facile da spostare, può tracciare se modificato (.Net1).
• Problema: è comunque necessario archiviare i dati specifici dell'utente in modo simile (ad es. Distribuzione xcopy).
• Soluzione: file XML USER.CONFIG nella cartella locale o in roaming dell'utente e fortemente tipizzato (.Net2).
• Problema: i file CONFIG fanno distinzione tra maiuscole e minuscole (non intuitivo per gli umani), richiedono "tag" di apertura / chiusura molto specifici, le stringhe di connessione non possono essere impostate in fase di esecuzione, i progetti di installazione non possono scrivere impostazioni (facilmente come il registro), non possono determinare facilmente Il file user.config e le impostazioni dell'utente vengono saltati con ogni nuova revisione installata.
• Soluzione: utilizzare il membro ITEM per impostare le stringhe di connessione in fase di runtime, scrivere codice in una classe Installer per modificare App.Config durante l'installazione e utilizzare le impostazioni dell'applicazione come impostazioni predefinite se non viene trovata un'impostazione utente.

Il mondo finirà se memorizzi alcune posizioni delle finestre e un elenco degli elementi utilizzati più di recente nel registro di Windows? Finora ha funzionato bene per me.

HKEY-CURRENT-USER è un ottimo posto per archiviare dati utente banali in piccole quantità. Ecco a cosa serve. Sembra sciocco non usare per lo scopo previsto solo perché altri lo hanno abusato.

Le impostazioni che si desidera rendere disponibili nel profilo di roaming di un utente dovrebbero probabilmente andare nel registro, a meno che non si desideri effettivamente cercare manualmente la cartella Dati applicazioni dell'utente. :-)

Le letture e le scritture del registro sono thread-safe ma i file no. Quindi dipende dal fatto che il tuo programma sia a thread singolo o meno.

Se stai sviluppando una nuova app e ti preoccupi della portabilità, non dovresti MAI archiviare i dati nel registro di Windows poiché altri sistemi operativi non dispongono di un registro (di Windows) (nota che questo può essere ovvio ma viene spesso trascurato).

Se stai sviluppando solo per piattaforme Win ... cerca di evitarlo il più possibile. I file di configurazione (eventualmente crittografati) sono una soluzione molto migliore. La memorizzazione dei dati nel registro non ha alcun vantaggio (l'archiviazione isolata è una soluzione molto migliore, ad esempio se si utilizza .NET).

Leggermente fuori tema, ma poiché vedo le persone preoccupate per la portabilità, l'approccio migliore che abbia mai usato è la classe QSettings di Qt. Estrae la memorizzazione delle impostazioni (registro su Windows, file delle preferenze XML su Mac OS e file Ini su Unix). Come cliente della classe, non devo passare un ciclo cerebrale a farmi domande sul registro o su qualsiasi altra cosa, funziona semplicemente (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

Di solito, se non si inseriscono le impostazioni nel registro, lo si utilizza principalmente per ottenere le impostazioni di Windows correnti, modificare le associazioni di file, ecc.
Ora, se è necessario rilevare se il software è già installato, è possibile effettuare una voce minima nel registro , questa è una posizione che puoi trovare in qualsiasi configurazione. Oppure cerca una cartella con un determinato nome in Dati applicazioni.

Se guardo la mia cartella Document and Settings, vedo molti software che usano la notazione Unix dot per l'impostazione delle cartelle: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (ecc.)

e in Dati applicazioni, varie cartelle con nomi di editor o nomi di software. Sembra essere l'attuale tendenza, almeno tra le applicazioni portatili ...
WinMerge utilizza un approccio leggermente diverso, memorizzando i dati nel registro, ma offrendo l'importazione e l'esportazione delle opzioni nella finestra di dialogo di configurazione.

Personalmente ho usato il registro per memorizzare i percorsi di installazione per l'uso da parte degli script (disinstallazione). Non sono sicuro che questa sia l'unica opzione possibile, ma sembrava una soluzione ragionevole. Questo era per un'app che era utilizzata esclusivamente su Windows, ovviamente.

In .NET NON c'è davvero bisogno.

Ecco 2 esempi che mostrano come utilizzare le proprietà del progetto per fare ciò.

Questi esempi lo fanno tramite le proprietà del progetto utente di Windows, ma lo stesso potrebbe / può essere fatto anche dall'applicazione.

Più qui:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

(in ritardo alla discussione ma) Risposta breve: Criteri di gruppo.

Se il reparto IT del cliente desidera applicare le impostazioni relative a Windows o ai componenti in cui si sta scrivendo o raggruppando, ad esempio una velocità di collegamento, un messaggio di errore personalizzato o un server di database a cui connettersi, questo è ancora in genere fatto tramite Criteri di gruppo, che si manifesta come impostazioni memorizzate nel registro. Tali criteri vengono applicati dal momento in cui Windows viene avviato o l'utente accede.

Esistono strumenti per creare modelli ADMX personalizzati in grado di mappare le impostazioni dei componenti alle posizioni del registro e fornire all'amministratore un'interfaccia comune per applicare le politiche che deve applicare, mostrando loro solo quelle impostazioni che sono significative per applicare in questo modo.

Credo che il registro di Windows sia stata una buona idea, ma a causa del grande abuso da parte degli sviluppatori di applicazioni e delle politiche standard non incoraggiate / imposte da Microsoft è diventata una bestia ingestibile. Odio usarlo per i motivi che hai citato, ci sono comunque alcune occasioni in cui ha senso usarlo:

• Lasciare una traccia dell'applicazione dopo che l'applicazione è stata disinstallata (ad es. Ricordare le preferenze dell'utente nel caso in cui l'applicazione venga nuovamente installata)
• Condividi le impostazioni di configurazione tra diverse applicazioni - componenti