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

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

Ao escrever meus próprios aplicativos, o que devo colocar no registro, e não em arquivos de configuração antigos, e por quê?

  • Originalmente (WIN3) 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 do 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 de leitura.
  • 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 movidos para a pasta de dados do aplicativo do usuário.
  • Problema: bom para grandes quantidades de dados, mas bastante 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ê-los. (Dados de leitura / gravação ou específicos do usuário permanecem no registro)

Chegando a isso tanto do ponto de vista do usuário quanto do programador, eu teria que dizer que realmente não há um grande benefício em 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 executado a partir de onde estiver 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, devem residir em um subdiretório do diretório de instalação, para que toda a instalação seja facilmente movida.

Eu uso um monte de utilitários menores, como programas, por isso, se ele não pode ser instalado em um pendrive e conectado a outra máquina e apenas executar, então não é para mim.

Política da Microsoft:

  • Antes do Windows 95, usamos arquivos ini para dados de aplicativos.
  • Nas janelas 95 – era XP, usamos o registro.
  • No Windows Vista, usamos arquivos ini, embora agora eles sejam baseados em xml.

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

Quando – Você é forçado a fazer devido à integração legada ou porque o administrador do sistema do seu cliente diz “deve ser assim” ou porque você está desenvolvendo em um idioma mais antigo que dificulta o uso do XML.

Por que – principalmente porque o registro não é tão portátil quanto copiar um arquivo de configuração que está próximo ao aplicativo (e é chamado quase o mesmo).

Se você estiver usando .Net2 + você tem arquivos App.Config e User.Config e você não precisa registrar DLLs no registro, então 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 headers de seção para agrupar dados (Win3.0).
  • Problema: O arquivo WIN.INI ficou muito grande (e ficou confuso).
  • Solução: armazene as configurações em arquivos INI na mesma pasta que o aplicativo (Win3.1).
  • Problema: precisa de configurações específicas do usuário.
  • Solução: armazene as configurações de usuário em arquivos INI específicos do usuário no diretório Window do usuário (Win3.11) ou em seções específicas do usuário no arquivo INI do aplicativo.
  • Problema: Segurança – algumas configurações de aplicativos 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: Registro específico do usuário movido para user.dat na pasta “Application Data” do usuário e carregado apenas no login (WinNT).
  • Problema: Em grandes ambientes corporativos, você faz logon em várias máquinas e precisa configurar EACH ONE.
  • Solução: Diferencie entre perfis locais (Configurações locais) e móveis (Dados de aplicativos) (WinXP).
  • Problema: Não é possível xcopy implantar ou mover aplicativos como o restante do .Net.
  • Solução: arquivo XML APP.CONFIG na mesma pasta que o aplicativo -, fácil de ler, fácil de manipluar, fácil de mover, pode rastrear se mudou (.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 fortemente tipado (.Net2).
  • Problema: os arquivos CONFIG diferenciam maiúsculas de minúsculas (não são intuitivos para humanos), exigem “tags” abertas / fechadas muito específicas, strings de conexão não podem ser definidas em tempo de execução, projetos de instalação não podem gravar configurações (tão facilmente quanto o registro) O arquivo user.config e as configurações do usuário são soprados com cada nova revisão instalada.
  • Solução: Use o membro ITEM para definir sequências de conexão em tempo de execução, escrever código em uma class Installer para alterar o App.Config durante a instalação e usar as configurações do aplicativo como padrão, se uma configuração de usuário não for encontrada.

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

O HKEY-CURRENT-USER é um ótimo lugar para armazenar dados triviais do usuário em pequenas quantidades. É para isso. Parece bobo não usar para o propósito pretendido só porque os outros abusaram dele.

As configurações que você deseja ter disponíveis no perfil móvel de um usuário provavelmente devem ser incluídas no registro, a menos que você realmente queira ir à procura da pasta Dados do Aplicativo do usuário manualmente. 🙂

As leituras e gravações do Registro são thread-safe, mas os arquivos não são. Então, depende se o seu programa é único ou não.

Se você está desenvolvendo um novo aplicativo e se preocupa com a portabilidade, NUNCA deve armazenar dados no registro do Windows, já que outro sistema operacional não possui um registro (Windows) (nota explicativa – isso pode ser óbvio, mas frequentemente ignorado).

Se você está apenas desenvolvendo para plataformas Win … tente evitá-lo o máximo possível. Arquivos de configuração (possivelmente criptografados) são uma solução muito melhor. Não há nenhum 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 do assunto, mas desde que vejo pessoas preocupadas com a portabilidade, a melhor abordagem que já usei é a class QSettings da Qt. Ele abstrai o armazenamento das configurações (registro no Windows, arquivo de preferências XML no Mac OS e arquivos Ini no Unix). Como um cliente da class, eu não tenho que gastar um ciclo cerebral me perguntando sobre o registro ou qualquer outra coisa, é apenas Works ™.

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

Normalmente, se você não colocar as configurações no registro, você a usará principalmente para obter configurações atuais do Windows, alterar associações de arquivos, etc.
Agora, se você precisa detectar se o seu software já está instalado, você pode fazer uma input mínima no registro, que é um local que você pode encontrar em qualquer configuração. Ou pesquise uma pasta de nome no Application Data.

Se eu olhar para a pasta Documentos e configurações, vejo muitos softwares usando a notação de ponto Unix para configurar pastas: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (etc.)

e em Application Data, várias pastas com nomes de editor ou nomes de software. Parece ser a tendência atual, pelo menos entre os aplicativos portáteis …
O WinMerge usa uma abordagem um pouco diferente, armazenando dados no registro, mas oferecendo Importação e Exportação de opções no diálogo de configuração.

Pessoalmente, usei o registro para armazenar os 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. Isso foi para um aplicativo que estava apenas em uso no Windows, é claro.

No .net realmente não é sempre uma necessidade.

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

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

Mais aqui:

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

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

(tarde 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 que você está gravando ou agrupando, como velocidade de link ou uma mensagem de erro personalizada, ou um servidor de database ao qual se conectar, ainda é comum feito via Group Policy, que faz sua manifestação final como configurações armazenadas no registro. Tais políticas são aplicadas a partir do momento em que o Windows é inicializado ou o usuário efetua login.

Existem ferramentas para criar modelos ADMX personalizados que podem mapear as configurações de seus componentes para os locais do Registro e fornecer ao administrador uma interface comum para impor as políticas que ele precisa aplicar ao mesmo tempo em que mostra apenas as configurações que são significativas para impor dessa maneira.

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

  • Deixando um rastreio de seu aplicativo depois que seu aplicativo foi desinstalado (por exemplo, lembre-se das preferências do usuário, caso o aplicativo seja instalado novamente)
  • Compartilhar configurações entre aplicativos diferentes – componentes
Intereting Posts