Quando e por que você deve armazenar dados no Registro do Windows?

Como desenvolvedor, as ferramentas que armazenam as configurações / opções no registro são a desgraça da minha vida. Não consigo rastrear facilmente as alterações nessas opções, não posso transportá-las facilmente de máquina para máquina, e tudo isso me faz realmente ansiar pelos bons velhos tempos dos arquivos .INI ...

Ao escrever meus próprios aplicativos, o que - se houver - devo escolher colocar no registro, em vez de nos arquivos de configuração antiquados, e por quê?

• Originalmente (WIN3), a configuração foi armazenada no arquivo WIN.INI no diretório do Windows.
• Problema: WIN.INI cresceu muito grande.
• Solução (Win31): arquivos INI individuais no mesmo diretório que o programa.
• Problema: Esse programa pode ser instalado em uma rede e compartilhado por muitas pessoas.
• Solução (Win311): arquivos INI individuais no diretório Window do usuário.
• Problema: Muitas pessoas podem compartilhar uma pasta do Windows, e ela deve ser somente leitura de qualquer maneira.
• Solução (Win95): Registro com seções separadas para cada usuário.
• Problema: o registro cresceu muito.
• Solução (WinXP): grandes blocos de dados individuais foram movidos para a pasta Dados do aplicativo do usuário.
• Problema: bom para grandes quantidades de dados, mas complexo para pequenas quantidades.
• Solução (.NET): pequenas quantidades de dados fixos, somente leitura, armazenados em arquivos .config (Xml) na mesma pasta do aplicativo, com a API para lê-lo. (Leitura / gravação ou dados específicos do usuário permanecem no registro)

Chegando a isso, tanto da perspectiva do usuário quanto da do programador, eu diria que não há realmente uma boa desculpa para colocar algo no registro, a menos que seja algo como associações de arquivos ou configurações específicas da máquina.

Eu venho da escola de pensamento que diz que um programa deve ser executável de onde quer que esteja instalado, que a instalação deve ser completamente móvel dentro de uma máquina ou mesmo para outra máquina e não afetar o funcionamento dela.

Quaisquer opções configuráveis ​​ou DLLs necessárias, etc, se não forem compartilhadas, deverão residir em um subdiretório do diretório de instalação, para que toda a instalação seja movida com facilidade.

Eu uso muitos utilitários menores, como programas, por isso, se ele não puder ser instalado em um pendrive e conectado a outra máquina e apenas rodar, não será para mim.

Política da Microsoft:

• Antes do Windows 95, usamos arquivos ini para dados do aplicativo.
• Na era do Windows 95 - XP, usamos o registro.
• No Windows Vista, usamos arquivos ini, embora agora eles sejam baseados em xml.

O registro depende da máquina. Eu nunca gostei porque está ficando lento e é quase impossível encontrar o que você precisa. É por isso que eu gosto de arquivos ini simples ou outros arquivos de configuração. Você sabe onde eles estão (pasta do aplicativo ou pasta do usuário) para que sejam fáceis de transportar e legíveis por humanos.

Quando - Você é obrigado a devido à integração herdada ou porque o administrador do sistema do cliente diz "deve ser assim" ou porque você está desenvolvendo em uma linguagem mais antiga que dificulta o uso do XML.

Por quê - Principalmente porque o registro não é tão portátil quanto copiar um arquivo de configuração que fica ao lado do aplicativo (e é chamado quase o mesmo).

Se você estiver usando o .Net2 +, terá os arquivos App.Config e User.Config e não precisará registrar as DLLs no registro, portanto, fique longe dele.

Os arquivos de configuração têm seus próprios problemas (veja abaixo), mas eles podem ser codificados e você pode alterar sua arquitetura.

• Problema: Os aplicativos precisavam de configurações configuráveis.
• Solução: armazene as configurações em um arquivo (WIN.INI) na pasta Windows - use os títulos das seções para agrupar dados (Win3.0).
• Problema: o arquivo WIN.INI ficou muito grande (e ficou confuso).
• Solução: armazene as configurações nos arquivos INI na mesma pasta do aplicativo (Win3.1).
• Problema: Precisa de configurações específicas do usuário.
• Solução: armazene as configurações do usuário em arquivos INI específicos do usuário no diretório Window do usuário (Win3.11) ou seções específicas do usuário no arquivo INI do aplicativo.
• Problema: Segurança - algumas configurações do aplicativo precisam ser somente leitura.
• Solução: Registro com segurança, bem como seções específicas do usuário e de toda a máquina (Win95).
• Problema: o registro cresceu muito.
• Solução: o registro específico do usuário foi movido para user.dat na pasta "Application Data" do usuário e carregada apenas no logon (WinNT).
• Problema: Em grandes ambientes corporativos, você efetua login em várias máquinas e precisa configurar CADA UMA.
• Solução: diferencie os perfis local (Configurações locais) e de roaming (Dados de aplicativos) (WinXP).
• Problema: Não é possível xcopy implantar ou mover aplicativos como o restante do .Net.
• Solução: o arquivo XML APP.CONFIG na mesma pasta do aplicativo - fácil de ler, fácil de manipular, fácil de mover, pode rastrear se alterado (.Net1).
• Problema: Ainda é necessário armazenar dados específicos do usuário de maneira semelhante (por exemplo, xcopy deploy).
• Solução: arquivo XML USER.CONFIG na pasta local ou móvel do usuário e com forte digitação (.Net2).
• Problema: os arquivos CONFIG diferenciam maiúsculas de minúsculas (não são intuitivos para humanos), exigem "tags" de abrir / fechar muito específicos, as cadeias de conexão não podem ser definidas no tempo de execução, os projetos de instalação não podem gravar configurações (tão facilmente quanto o registro), não podem determinar facilmente O arquivo user.config e as configurações do usuário são expandidos a cada nova revisão instalada.
• Solução: use o membro ITEM para definir cadeias de conexão em tempo de execução, escreva o código em uma classe Installer para alterar o App.Config durante a instalação e use as configurações do aplicativo como padrão se uma configuração do usuário não for encontrada.

O mundo vai acabar se você armazenar algumas posições da janela e uma lista dos itens usados ​​mais recentemente no registro do Windows? Até agora, funcionou bem para mim.

O HKEY-CURRENT-USER é um ótimo local para armazenar dados triviais do usuário em pequenas quantidades. É para isso que serve. Parece bobagem não usar para o propósito a que se destina, apenas porque outros a abusaram.

As configurações que você deseja disponibilizar no perfil móvel de um usuário provavelmente devem estar no registro, a menos que você queira realmente procurar a pasta Dados do Aplicativo do usuário manualmente. :-)

As leituras e gravações do registro são seguras contra threads, mas os arquivos não. Portanto, depende se o seu programa é ou não único.

Se você estiver desenvolvendo um novo aplicativo e se preocupa com a portabilidade, NUNCA armazene dados no registro do Windows, pois outro sistema operacional não possui um registro (windows) (nota duh - isso pode ser óbvio, mas muitas vezes esquecido).

Se você está desenvolvendo apenas para plataformas Win ... tente evitá-lo o máximo possível. Os arquivos de configuração (possivelmente criptografados) são uma solução muito melhor. Não há ganho em armazenar dados no registro - (o armazenamento isolado é uma solução muito melhor, por exemplo, se você estiver usando o .NET).

Um pouco fora de tópico, mas como vejo pessoas preocupadas com portabilidade, a melhor abordagem que já usei é a classe QSettings do Qt. Ele abstrai o armazenamento das configurações (registro no Windows, arquivo de preferência XML no Mac OS e arquivos Ini no Unix). Como cliente da classe, não preciso passar um ciclo cerebral imaginando sobre o registro ou qualquer outra coisa, apenas funciona (tm).

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

Normalmente, se você não coloca as configurações no registro, usa-as principalmente para obter as configurações atuais do Windows, alterar associações de arquivos etc.
Agora, se precisar detectar se o software já está instalado, você pode fazer uma entrada mínima no registro , é um local que você pode encontrar em qualquer configuração. Ou pesquise uma pasta com o nome especificado em Dados do aplicativo.

Se eu olhar para a minha pasta Document and Settings, vejo muitos softwares usando a notação de ponto Unix para definir pastas: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (etc.)

e em Dados do aplicativo, várias pastas com nomes de editor ou nomes de software. Parece ser a tendência atual, pelo menos entre aplicativos portáteis ... O
WinMerge usa uma abordagem ligeiramente diferente, armazenando dados no registro, mas oferecendo a opção Importar e Exportar opções na caixa de diálogo de configuração.

Pessoalmente, usei o registro para armazenar caminhos de instalação para uso pelos scripts de (des) instalação. Não tenho certeza se essa é a única opção possível, mas parecia uma solução sensata. Era para um aplicativo que estava sendo usado apenas no Windows, é claro.

No .NET realmente não há necessidade.

Aqui estão 2 exemplos que mostram como usar as propriedades do projeto para fazer isso.

Esses exemplos fazem isso pelas propriedades do projeto de usuário do Windows, mas o mesmo pode / pode ser feito pelo aplicativo também.

Mais aqui:

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

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

(atrasado para a discussão, mas) Resposta curta: Diretiva de Grupo.

Se o departamento de TI do seu cliente quiser impor configurações relacionadas ao Windows ou aos componentes nos quais você está escrevendo ou agrupando, como velocidade do link ou mensagem de erro personalizada ou servidor de banco de dados ao qual se conectar, isso ainda é normalmente feito via Diretiva de Grupo, que faz sua manifestação final como configurações armazenadas no registro. Essas políticas são aplicadas a partir do momento em que o Windows é iniciado ou o usuário faz login.

Existem ferramentas para criar modelos ADMX personalizados que podem mapear as configurações de seus componentes para locais de registro e fornecer ao administrador uma interface comum para impor políticas que ele precisa impor, mostrando a eles apenas as configurações que são significativas para impor dessa maneira.

Acredito que o Registro do Windows foi uma boa ideia, mas por causa de um grande abuso por parte dos desenvolvedores de aplicativos e de políticas padrão não incentivadas / exigidas pela Microsoft, tornou-se uma fera incontrolável. Eu odeio usá-lo pelas razões mencionadas, no entanto, há algumas ocasiões em que faz sentido usá-lo:

• Deixando um rastreio do seu aplicativo após a desinstalação do aplicativo (por exemplo, lembre-se das preferências do usuário caso o aplicativo seja instalado novamente)
• Compartilhar definições de configuração entre diferentes aplicativos - componentes