¿Cuándo y por qué debería almacenar datos en el Registro de Windows?

126

Como desarrollador, las herramientas que almacenan la configuración / opciones en el registro son la ruina de mi vida. No puedo rastrear fácilmente los cambios a esas opciones, no puedo portarlos fácilmente de una máquina a otra, y todo me hace realmente anhelar los viejos tiempos de los archivos .INI ...

Al escribir mis propias aplicaciones, ¿qué, si es que hay algo, debería elegir incluir en el registro en lugar de en los archivos de configuración anticuados, y por qué?

windows registry Roddy
fuente
Ahora mismo trabajo con una aplicación heredada que almacena información en el registro (aplicación .NET) y me vuelve loco.
George Stocker

Respuestas:

75
  • La configuración original (WIN3) se almacenó en el archivo WIN.INI en el directorio de Windows.
  • Problema: WIN.INI creció demasiado.
  • Solución (Win31): archivos INI individuales en el mismo directorio que el programa.
  • Problema: ese programa puede instalarse en una red y ser compartido por muchas personas.
  • Solución (Win311): archivos INI individuales en el directorio de Windows del usuario.
  • Problema: muchas personas pueden compartir una carpeta de Windows, y de todos modos debería ser de solo lectura.
  • Solución (Win95): Registro con secciones separadas para cada usuario.
  • Problema: el registro creció demasiado.
  • Solución (WinXP): grandes bloques de datos individuales movidos a la carpeta de datos de la aplicación del usuario.
  • Problema: Bueno para grandes cantidades de datos, pero bastante complejo para pequeñas cantidades.
  • Solución (.NET): pequeñas cantidades de datos fijos de solo lectura almacenados en archivos .config (Xml) en la misma carpeta que la aplicación, con API para leerlos. (Los datos específicos de lectura / escritura o usuario permanecen en el registro)
James Curran
fuente
16
Unix: configuración almacenada en $ HOME / .your-app Allí, resuelta en una iteración.
Leonel
33
La solución Unix está lejos de ser ideal también: $ HOME está repleto de archivos de puntos, y no tienes idea de lo que hacen la mayoría de ellos.
grep
2
@Leonel XDG en realidad exige que coloque sus archivos de configuración en el interior $HOME/.config/your-app/, una solución creada para tratar el problema con los objetos @grep. Y, sorprendentemente, el Linux moderno (y cualquiera en el * BSD es lo suficientemente loco como para usar GNOME) también tiene un registro en la gconfsuite. FOSS genera opciones, eso es seguro;)
nuevo123456
1
@grep, Re " no tengo idea de qué hacen la mayoría de ellos ", ¿por qué no? Además, la hinchazón no es comparable con la de Windows.
Pacerier
16

Llegando a esto tanto desde la perspectiva del usuario como desde la perspectiva de los programadores, tendría que decir que realmente no hay una buena excusa para incluir algo en el registro a menos que sea algo como asociaciones de archivos o configuraciones específicas de la máquina.

Vengo de la escuela de pensamiento que dice que un programa debe ser ejecutable desde donde esté instalado, que la instalación debe ser completamente móvil dentro de una máquina, o incluso a otra máquina y no afectar el funcionamiento del mismo.

Cualquier opción configurable, o dlls requeridos, etc., si no se comparten, debe residir en un subdirectorio del directorio de instalación, de modo que toda la instalación se pueda mover fácilmente.

Utilizo muchos programas de utilidad más pequeños, por lo que si no se puede instalar en un dispositivo USB y enchufarlo a otra máquina y simplemente ejecutarlo, entonces no es para mí.

Jimoc
fuente
44
Pero la instalación a menudo se realiza bajo control administrativo, mientras que la actualización de la configuración se debe realizar bajo control del usuario. Imagínese tratando de actualizar la configuración: una aplicación que se ejecuta con la identidad del usuario y que desea escribir en un directorio restringido solo para acceso de administrador. Esta es una de las cosas que el registro pretende abordar.
Cheeso
@Cheeso, la solución es que cada usuario tenga una copia del ejecutable. Para ahorrar espacio, no una copia real sino solo una copia falsa (puntero).
Pacerier
12

Política de Microsoft:

  • Antes de Windows 95, utilizamos archivos ini para los datos de la aplicación.
  • En la era de Windows 95 - XP, utilizamos el registro.
  • Desde Windows Vista, utilizamos archivos ini aunque ahora están basados ​​en xml.

El registro depende de la máquina. Nunca me ha gustado porque se está ralentizando y es casi imposible encontrar lo que necesita. Es por eso que me gusta ini simple u otros archivos de configuración. Usted sabe dónde están (carpeta de aplicación o carpeta de usuario) para que sean fáciles de transportar y legibles por humanos.

Toon Krijthe
fuente
1
¿Puede proporcionar un enlace original al documento que establezca esta política de microsoft? Y cuando dice política, ¿quiere decir que esto es lo que hace Microsoft, o quiere decir que esto es lo que Microsoft recomienda a los desarrolladores que crean aplicaciones para Windows?
Cheeso
1
ps: raymond Chen de Microsoft ha declarado que los archivos INI están en desuso a favor del Registro, y explica por qué. blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx También afirma que los archivos XML tienen muchos de los mismos inconvenientes que los archivos ini.
Cheeso
8
Archivos de configuración XML = archivos INI que son más difíciles de analizar
Robert Fraser
3
@Fraser si cree que analizar XML es difícil, está en el negocio equivocado.
SnakeDoc
@SnakeDoc, Harder no significa más difícil. Simplemente significa un análisis y retraso más lento.
Pacerier
12

Cuándo : se ve obligado a hacerlo debido a la integración heredada o porque el administrador del sistema de su cliente dice "será así" o porque está desarrollando en un lenguaje antiguo que hace que sea más difícil usar XML.

Por qué : principalmente porque el registro no es tan portátil como copiar un archivo de configuración que se encuentra junto a la aplicación (y se llama casi lo mismo).

Si está utilizando .Net2 +, tiene los archivos App.Config y User.Config y no necesita registrar DLL en el registro, así que manténgase alejado de él.

Los archivos de configuración tienen sus propios problemas (ver más abajo), pero estos pueden codificarse y puede alterar su arquitectura.

  • Problema: las aplicaciones necesitaban configuraciones configurables.
  • Solución: almacene la configuración en un archivo (WIN.INI) en la carpeta de Windows; utilice encabezados de sección para agrupar datos (Win3.0).
  • Problema: el archivo WIN.INI creció demasiado (y se volvió desordenado).
  • Solución: almacene la configuración en archivos INI en la misma carpeta que la aplicación (Win3.1).
  • Problema: necesita configuraciones específicas del usuario.
  • Solución: almacene la configuración del usuario en archivos INI específicos del usuario en el directorio de Windows del usuario (Win3.11) o secciones específicas del usuario en el archivo INI de la aplicación.
  • Problema: seguridad: algunas configuraciones de la aplicación deben ser de solo lectura.
  • Solución: Registro con seguridad, así como secciones específicas del usuario y de toda la máquina (Win95).
  • Problema: el registro creció demasiado.
  • Solución: el registro específico del usuario se movió a user.dat en la carpeta "Datos de la aplicación" del usuario y solo se cargó al iniciar sesión (WinNT).
  • Problema: en entornos corporativos grandes, inicia sesión en varias máquinas y tiene que configurar CADA UNA.
  • Solución: diferencie entre perfiles locales (Configuración local) y roaming (Datos de aplicación) (WinXP).
  • Problema: no se puede xcopy implementar o mover aplicaciones como el resto de .Net.
  • Solución: archivo XML APP.CONFIG en la misma carpeta que la aplicación, fácil de leer, fácil de manipular, fácil de mover, puede rastrear si se modifica (.Net1).
  • Problema: todavía es necesario almacenar datos específicos del usuario de manera similar (es decir, implementación de xcopy).
  • Solución: archivo XML USER.CONFIG en la carpeta local o móvil del usuario y fuertemente tipado (.Net2).
  • Problema: los archivos CONFIG distinguen entre mayúsculas y minúsculas (no son intuitivos para los humanos), requieren "etiquetas" de apertura / cierre muy específicas, las cadenas de conexión no se pueden establecer en tiempo de ejecución, los proyectos de configuración no pueden escribir configuraciones (tan fácilmente como el registro), no pueden determinar fácilmente El archivo user.config y la configuración del usuario se vuelan con cada nueva revisión instalada.
  • Solución: use el miembro ITEM para establecer cadenas de conexión en tiempo de ejecución, escriba el código en una clase de instalador para cambiar la aplicación. Configure durante la instalación y use la configuración de la aplicación como predeterminada si no se encuentra una configuración de usuario.
AndrewD
fuente
Esta es una respuesta mucho más completa que la aprobada. Gracias @ AndrewD.
Rotman
8

¿Se acabará el mundo si almacena algunas posiciones de ventana y una lista de los elementos usados ​​más recientemente en el registro de Windows? Me ha funcionado bien hasta ahora.

HKEY-CURRENT-USER es un excelente lugar para almacenar datos triviales de usuarios en pequeñas cantidades. Para eso es. Parece una tontería no usarlo para el propósito previsto solo porque otros lo han abusado.

Angus Glashier
fuente
y es excelente para corromperse a sí mismo ... eso es una ventaja. Menos trabajo para el usuario ...
SnakeDoc
4

La configuración que desea tener disponible en el perfil móvil de un usuario probablemente debería ir al registro, a menos que realmente quiera esforzarse por buscar la carpeta de Datos de la aplicación del usuario a mano. :-)

Chris Jester-Young
fuente
4

Las lecturas y escrituras del registro son seguras para subprocesos pero los archivos no. Por lo tanto, depende de si su programa tiene un solo subproceso o no.

Martín
fuente
2

Si está desarrollando una nueva aplicación y le preocupa la portabilidad, NUNCA debe almacenar datos en el registro de Windows, ya que otros sistemas operativos no tienen un registro (Windows) (nota: esto puede ser obvio, pero a menudo se pasa por alto).

Si solo está desarrollando para plataformas Win ... intente evitarlo tanto como sea posible. Los archivos de configuración (posiblemente cifrados) son una solución mucho mejor. No hay ganancia en el almacenamiento de datos en el registro (el almacenamiento aislado es una solución mucho mejor, por ejemplo, si está usando .NET).

JohnIdol
fuente
Esto es parcialmente cierto. Mono ha implementado el espacio de nombres Microsoft.win32 para registros, excepto que lo almacena en un archivo en ~ / .mono / Registry en un archivo xml, y se maneja de manera transparente. Ahora bien, si usted podría dar vuelta la manipulación en cualquier aplicación de XML, independientemente de la plataforma ...
Robert P
Nota: solo está disponible si está escribiendo una aplicación .NET / Mono.
Robert P
El registro ofrece una ganancia: los datos son más fácilmente accesibles en una aplicación multiproceso. Más importante aún, le permite separar los datos de configuración que son específicos de la máquina frente a los específicos del usuario. No es necesario que su aplicación sepa quién está conectado cuando accede a HKEY_CURRENT_USER. Sin embargo, tienes razón sobre la portabilidad.
James
2

Ligeramente fuera de tema, pero dado que veo personas preocupadas por la portabilidad, el mejor enfoque que he usado es la clase QSettings de Qt. Resume el almacenamiento de la configuración (registro en Windows, archivo de preferencias XML en Mac OS e archivos Ini en Unix). Como cliente de la clase, no tengo que pasar un ciclo cerebral preguntándome sobre el registro o cualquier otra cosa, simplemente funciona (tm).

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

rlerallut
fuente
Parece que la url ya no funciona. Una referencia de actualización debe ser qt-project.org/doc/qt-5/QSettings.html#details
Eineki
0

Por lo general, si no coloca la configuración en el registro, la usa principalmente para obtener la configuración actual de Windows, cambiar las asociaciones de archivos, etc.
Ahora, si necesita detectar si su software ya está instalado, puede hacer una entrada mínima en el registro , esa es una ubicación que puedes encontrar en cualquier configuración. O busque una carpeta de nombre en los Datos de la aplicación.

Si miro mi carpeta Documento y Configuración, veo muchos softwares que usan la notación de puntos Unix para configurar carpetas: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (etc.)

y en Application Data, varias carpetas con nombres de editor o nombres de software. Parece ser la tendencia actual, al menos entre las aplicaciones portátiles ...
WinMerge utiliza un enfoque ligeramente diferente, almacenando datos en el registro, pero ofreciendo opciones de importación y exportación en el diálogo de configuración.

PhiLho
fuente
La notación de puntos de Unix que ve es probablemente porque todos esos ejemplos son de proyectos de código abierto portados, no porque sea una mejor práctica para el desarrollo de Windows.
James
De hecho, no dije que fuera una "mejor práctica", sino una práctica común ... :) Las carpetas en datos de aplicaciones / son / mejores prácticas, particularmente para datos grandes, pero también porque son más fáciles de respaldar.
PhiLho
0

Personalmente, he utilizado el registro para almacenar rutas de instalación para que las utilicen los scripts de (des) instalación. No estoy seguro de si esta es la única opción posible, pero parecía una solución sensata. Esto fue para una aplicación que solo estaba en uso en Windows, por supuesto.

chillysapien
fuente
0

(tarde a la discusión pero) Respuesta breve: Política de grupo.

Si el departamento de TI de su cliente desea imponer configuraciones relacionadas con Windows o los componentes que está escribiendo o agrupando, como la velocidad de un enlace, un mensaje de error personalizado o un servidor de base de datos para conectarse, esto sigue siendo típicamente hecho a través de la Política de grupo, que hace su máxima manifestación como configuraciones almacenadas en el registro. Dichas políticas se aplican desde el momento en que Windows se inicia o el usuario inicia sesión.

Existen herramientas para crear plantillas ADMX personalizadas que pueden asignar la configuración de sus componentes a ubicaciones de registro, y darle al administrador una interfaz común para hacer cumplir las políticas que necesita hacer cumplir al mostrarles solo las configuraciones que son significativas para hacer cumplir de esta manera.

Spencer
fuente
-1

Creo que el Registro de Windows fue una buena idea, pero debido al gran abuso de los desarrolladores de aplicaciones y las políticas estándar no recomendadas / ordenadas por Microsoft se convirtió en una bestia inmanejable. Odio usarlo por las razones que ha mencionado, sin embargo, hay algunas ocasiones en que tiene sentido usarlo:

  • Dejar un rastro de su aplicación después de que su aplicación se haya desinstalado (por ejemplo, recuerde las preferencias del usuario en caso de que la aplicación se vuelva a instalar)
  • Compartir ajustes de configuración entre diferentes aplicaciones - componentes
kgiannakakis
fuente
55
No estoy de acuerdo con usted con respecto a su primer punto, "[l] dejar un rastro de su aplicación después de que su aplicación haya sido desinstalada". Prefiero que si digo "quítate de mi sistema" que tu aplicación cumpla por completo. Supongo que sería diferente si le preguntaras al usuario si está bien dejar algo atrás, pero incluso entonces probablemente me gustaría que fuera un archivo de configuración guardado. A pesar de las licencias, etc., si está vendiendo su computadora y comprando una nueva, ¿no preferiría tener un archivo de configuración que pueda cargar en la nueva instalación en lugar de algo relacionado con la computadora que está vendiendo?
AgentConundrum
2
Muchas aplicaciones hacen esto y tiene razón al decir que no es algo muy bueno, especialmente si lo hacen sin el permiso del usuario. Sin embargo, a menudo es la funcionalidad que los usuarios esperan de una aplicación (la mayoría de los usuarios no saben qué es el registro). Los usuarios solo esperan encontrar sus configuraciones automáticamente de nuevo, cuando desinstalan e instalan nuevamente.
kgiannakakis
2
Creo que nos encontramos un autor de malware aquí. Nunca deje basura de su programa en el sistema de alguien si le pidieron que desinstale. Al menos pregúnteles si quieren recordar configuraciones, etc. Nunca lo haga. ¿Qué sucede si almacena una clave de licencia y vendo mi computadora? ¿Qué sucede si su programa estaba causando problemas en mi computadora e intenté desinstalarlo para solucionarlo? Bueno, las sobras de tu registro podrían causarme muchos problemas. Solo no lo hagas. Solo no lo hagas.
SnakeDoc