Quando e perché conservare 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 posso portarle facilmente da una macchina all’altra, e tutto ciò mi fa davvero desiderare i bei vecchi tempi dei file .INI …

Quando scrivo le mie applicazioni personali, cosa – se non altro – dovrei scegliere di inserire il registro piuttosto che i file di configurazione obsoleti, e perché?

  • La configurazione originariamente (WIN3) è stata memorizzata 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 potrebbero condividere una cartella di Windows e 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 memorizzati in file .config (Xml) nella stessa cartella dell’applicazione, con API per leggerlo. (Leggi / scrivi 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 è un buon esempio di mettere qualcosa nel registro a meno che non si tratti di associazioni di file o di impostazioni specifiche della macchina.

Vengo dalla scuola di pensiero che dice che un programma dovrebbe essere eseguibile ovunque 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.

Qualsiasi opzione configurabile, o dll richieste, ecc., Se non sono condivise, dovrebbero risiedere in una sottodirectory della directory di installazione, in modo che l’intera installazione possa essere facilmente spostata.

Io uso un sacco di 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 basta eseguire, quindi non è per me.

Politica Microsoft:

  • Prima di Windows 95, abbiamo utilizzato i file ini per i dati dell’applicazione.
  • Nell’era di Windows 95 – XP, abbiamo usato il registro.
  • Da Windows Vista, utilizziamo i file ini anche se ora sono basati su xml.

Il registro è dipendente dalla macchina. Non mi è mai piaciuto perché rallenta ed è quasi imansible trovare la cosa che ti serve. Ecco perché mi piacciono i file ini o altri file di impostazione. Sai dove sono (cartella dell’applicazione o cartella utente) in modo che siano facilmente trasportabili e leggibili.

Quando – Sei costretto a causa dell’integrazione legacy o perché l’amministratore di sistema del tuo cliente dice “deve essere così” o perché stai sviluppando in una lingua più vecchia che rende più difficile l’uso di XML.

Perché – Principalmente perché il registro non è così portatile come copiare un file di configurazione che si trova accanto all’applicazione (e viene chiamato 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 richiedevano impostazioni configurabili.
  • Soluzione: memorizzare 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: richiedono impostazioni specifiche dell’utente.
  • Soluzione: memorizzare le impostazioni utente in file INI specifici dell’utente nella directory Window dell’utente (Win3.11) o nelle sezioni specifiche dell’utente nel file INI dell’applicazione.
  • Problema: sicurezza: alcune impostazioni dell’applicazione devono essere di sola lettura.
  • Soluzione: registro con sicurezza e sezioni specifiche per utente e macchina (Win95).
  • Problema: il registro è diventato troppo grande.
  • Soluzione: il registro specifico dell’utente è stato spostato su user.dat nella cartella “Dati applicazioni” dell’utente e caricato solo al login (WinNT).
  • Problema: in ambienti aziendali di grandi dimensioni si accede a più computer e si deve impostare EACH ONE su.
  • Soluzione: distinguere tra i profili locali (Impostazioni locali) e di roaming (Dati applicazioni) (WinXP).
  • Problema: non è ansible distribuire o spostare xcopy applicazioni come il resto di .Net.
  • Soluzione: file XML APP.CONFIG nella stessa cartella dell’applicazione – facile da leggere, facile da manipolare, facile da spostare, tracciabile se modificato (.Net1).
  • Problema: è comunque necessario memorizzare i dati specifici dell’utente in modo simile (ad es. Xcopy deploy).
  • Soluzione: file XML USER.CONFIG nella cartella locale o roaming dell’utente e fortemente tipizzato (.Net2).
  • Problema: i file CONFIG sono case-sensitive (non intuitivi per gli umani), richiedono tag “open / close” molto specifici, le stringhe di connessione non possono essere impostate in fase di esecuzione, i progetti di installazione non possono scrivere le impostazioni (con la stessa facilità del registro), non possono determinare facilmente il file user.config e le impostazioni utente sono saltati con ogni nuova revisione installata.
  • Soluzione: utilizzare il membro ITEM per impostare le stringhe di connessione in fase di esecuzione, scrivere il codice in una class Installer per modificare App.Config durante l’installazione e utilizzare le impostazioni dell’applicazione come predefinite se non viene trovata un’impostazione utente.

Il mondo sta per finire se si memorizzano alcune posizioni della finestra 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 il suo scopo solo perché altri lo hanno abusato.

Le impostazioni che si desidera siano disponibili nel profilo di roaming di un utente dovrebbero probabilmente essere inserite nel registro, a meno che non si desideri eseguire manualmente la ricerca della cartella Dati applicazioni dell’utente. 🙂

Le letture e le scritture del registro sono a prova di codice ma i file non lo sono. Quindi dipende dal fatto che il tuo programma sia o meno a thread singolo.

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

Se stai sviluppando solo per piattaforms Win … cerca di evitarlo il più ansible. I file di configurazione (possibilmente crittografati) sono una soluzione migliore. Non c’è alcun vantaggio nell’archiviazione dei dati nel registro – (l’archiviazione isolata è una soluzione molto migliore, ad esempio se si utilizza .NET).

Un po ‘fuori tema, ma dal momento che vedo persone preoccupate per la portabilità, l’approccio migliore che abbia mai utilizzato è la class QS di QSettings. Estrae la memorizzazione delle impostazioni (registro su Windows, file delle preferenze XML su Mac OS e file Ini su Unix). Come cliente della class, non devo passare un ciclo cerebrale a interrogarmi sul registro o su qualsiasi altra cosa, funziona semplicemente ™.

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 correnti di Windows, modificare le associazioni di file, ecc.
Ora, se è necessario rilevare se il software è già installato, è ansible inserire una voce minima nel registro, che è una posizione che è ansible trovare in qualsiasi configurazione. Oppure cerca una cartella con un nome specifico in Dati applicazione.

Se guardo la mia cartella Document and Settings, vedo molti software usando la notazione dot Unix 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 applicazione, varie cartelle con nomi di editor o nomi di software. Sembra essere la tendenza attuale, almeno tra le applicazioni portatili …
WinMerge utilizza un approccio leggermente diverso, memorizzando i dati nel registro, ma offrendo le opzioni di importazione ed esportazione nella finestra di configurazione.

Personalmente ho utilizzato il registro per archiviare percorsi di installazione da utilizzare con gli script (non) di installazione. Non sono sicuro che questa sia l’unica opzione ansible, ma mi sembra una soluzione ragionevole. Questo era per un’app che era esclusivamente in uso su Windows, ovviamente.

In .NET non c’è davvero mai un bisogno.

Qui ci sono 2 esempi che mostrano come usare Project Proerties per fare ciò.

Questi esempi fanno ciò con 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 tuo cliente desidera applicare le impostazioni relative a Windows o ai componenti in cui stai scrivendo o raggruppando, ad esempio una velocità di collegamento o un messaggio di errore personalizzato o un server di database a cui connettersi, questo è ancora in genere fatto tramite i Criteri di gruppo, che fa la sua massima manifestazione come impostazioni memorizzate nel registro. Tali politiche vengono applicate dal momento in cui Windows si avvia o l’utente effettua l’accesso.

Esistono strumenti per creare modelli ADMX personalizzati che possono mappare le impostazioni dei componenti nelle posizioni del registro e fornire all’amministratore un’interfaccia comune per applicare le politiche che deve applicare, pur mostrando solo le impostazioni che sono significative da applicare in questo modo.

Credo che il registro di Windows fosse una buona idea, ma a causa di un grande abuso da parte degli sviluppatori di applicazioni e di politiche standard non incoraggiate / obbligatorie da parte di Microsoft, si è trasformata in una bestia ingestibile. Odio usarlo per le ragioni che hai menzionato, tuttavia ci sono alcune occasioni in cui ha senso usarlo:

  • Lasciare una traccia della tua applicazione dopo che la tua applicazione è stata disinstallata (es. Ricorda le preferenze dell’utente nel caso in cui l’applicazione sia di nuovo installata)
  • Condividi le impostazioni di configurazione tra diverse applicazioni – componenti