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

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é?

• 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)

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í.

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.

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.

¿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.

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. :-)

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.

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).

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

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.

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.

En .NET realmente nunca hay una necesidad.

Aquí hay 2 ejemplos que muestran cómo usar las proezas del Proyecto para hacer esto.

Estos ejemplos lo hacen las Propiedades del proyecto de usuario de Windows, pero la Aplicación también podría / puede hacer lo mismo.

Más aquí:

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

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

(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.

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