registros - remove windows registry keys
¿Cuándo y por qué debería almacenar datos en el Registro de Windows? (14)
Como desarrollador, las herramientas que almacenan configuración / opciones en el registro son la perdición de mi vida. No puedo rastrear fácilmente los cambios en esas opciones, no puedo transferirlos fácilmente de una máquina a otra, y todo me hace anhelar los buenos viejos tiempos de los archivos .INI ...
Cuando escribo mis propias aplicaciones, ¿qué debo hacer? ¿Debo elegir incluir el registro en vez de archivos de configuración pasados de moda y por qué?
¿Se va a acabar el mundo si almacena algunas posiciones de ventana y una lista de los artículos usados más recientemente en el registro de Windows? Hasta ahora ha funcionado bien para mí.
HKEY-CURRENT-USER es un excelente lugar para almacenar datos de usuario triviales en pequeñas cantidades. Para eso es para eso. Parece una tontería no usar para su propósito previsto solo porque otros lo hayan abusado.
(tarde para 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 una velocidad de enlace, un mensaje de error personalizado o un servidor de base de datos para conectarse, esto todavía es típico hecho a través de la política de grupo, que hace su máxima manifestación como la configuración almacenada en el registro. Tales políticas se aplican desde el momento en que Windows se inicia o cuando el usuario inicia sesión.
Existen herramientas para crear plantillas personalizadas de ADMX que pueden asignar la configuración de sus componentes a las ubicaciones de registro, y le dan al administrador una interfaz común para aplicar las políticas que necesita imponer y al mismo tiempo mostrarles aquellas 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 ni obligatorias por Microsoft se convirtió en una bestia inmanejable. Odio usarlo por las razones que has mencionado, sin embargo, hay algunas ocasiones en las que tiene sentido usarlo:
- Dejar un rastro de su aplicación después de que su aplicación haya sido desinstalada (por ejemplo, recuerde las preferencias del usuario en caso de que la aplicación se instale nuevamente)
- Compartir configuración de configuración entre diferentes aplicaciones - componentes
En .NET realmente NO hay necesidad alguna vez.
Aquí hay 2 ejemplos que muestran cómo usar Project Proerties para hacer esto.
Estos ejemplos lo hacen las propiedades del proyecto de usuario de Windows, pero la aplicación también puede hacer lo mismo.
Más aquí:
En vista de esto, tanto desde la perspectiva del usuario como desde la perspectiva de los programadores, tendría que decir que realmente no es bueno exponer algo en el registro a menos que sea algo así como asociaciones de archivos o configuraciones específicas de la máquina.
Vengo de la escuela de pensamiento que dice que un programa debe poder ejecutarse 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 de la misma.
Cualquier opción configurable o dll requerida, etc., si no se comparten, debe residir en un subdirectorio del directorio de instalación, de modo que toda la instalación se mueva fácilmente.
Utilizo una gran cantidad de programas similares a los de una utilidad más pequeña, por lo que si no puede instalarse en un dispositivo USB y enchufarse a otra máquina y ejecutar, entonces no es para mí.
Es probable que la configuración que desea tener disponible en el perfil móvil de un usuario vaya en el registro, a menos que realmente desee realizar el esfuerzo de buscar manualmente la carpeta Datos de la aplicación del usuario. :-)
Las lecturas y escrituras del registro son enhebrables pero los archivos no lo son. Entonces depende de si su programa tiene o no un solo hilo.
Personalmente, he usado el registro para almacenar las rutas de instalación para que las guiones de (des) instalación puedan utilizar. No estoy seguro de si esta es la única opción posible, pero parecía una solución sensata. Esto era para una aplicación que solo estaba en uso en Windows, por supuesto.
Política de Microsoft:
- Antes de Windows 95, usamos archivos ini para datos de aplicaciones.
- En la era Windows 95 - XP, usamos el registro.
- Desde Windows Vista, usamos archivos ini aunque ahora están basados en xml.
El registro depende de la máquina. Nunca me ha gustado porque se está volviendo lento y es casi imposible encontrar lo que necesita. Es por eso que me gusta Ini simple u otros archivos de configuración. Ya sabes dónde están (carpeta de la aplicación o una carpeta de usuario) para que sean fáciles de transportar y legibles para el ser humano.
Por lo general, si no pone la configuración en el registro, la usa sobre todo para obtener la configuración actual de Windows, cambiar 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 puede encontrar en cualquier configuración. O busque una carpeta de nombre de pila en Datos de aplicación.
Si miro mi carpeta de documentos y configuraciones, veo muchos softwares usando la notación de puntos de Unix para establecer 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 software. Parece ser la tendencia actual, al menos entre aplicaciones portátiles ...
WinMerge utiliza un enfoque ligeramente diferente, almacena datos en el registro, pero ofrece las opciones Importar y Exportar en el cuadro de diálogo de configuración.
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 (de Windows) (nota dudosa: esto puede ser obvio, pero a menudo se pasa por alto).
Si solo está desarrollando plataformas Win ... intente evitarlo tanto como sea posible. Los archivos de configuración (posiblemente encriptados) 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 usa .NET).
Un poco fuera de tema, pero como veo gente preocupada por la portabilidad, el mejor enfoque que he usado es la clase QSettings de Qt. Resume el almacenamiento de las configuraciones (registro en Windows, archivo de preferencias XML en Mac OS y 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).
Cuándo : se ve obligado a hacerlo debido a una integración heredada o porque el administrador del sistema de su cliente dice "así será" o porque está desarrollando un lenguaje más 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 usa .Net2 +, tiene los archivos App.Config y User.Config y no necesita registrar las DLL en el registro, así que aléjese de ello.
Los archivos de configuración tienen sus propios problemas (ver a continuación), pero estos pueden codificarse y usted puede modificar su arquitectura.
- Problema: las aplicaciones necesitaban configuraciones configurables.
- Solución: Almacene la configuración en un archivo (WIN.INI) en la carpeta de Windows: use los títulos de las secciones para agrupar los 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 la ventana 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 propia 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 UNO.
- Solución: Diferenciar entre perfiles locales (configuraciones locales) y itinerantes (datos de aplicaciones) (WinXP).
- Problema: Xcopy no puede 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 ha cambiado (.Net1).
- Problema: Aún necesita almacenar datos específicos del usuario de manera similar (es decir, xcopy deploy).
- Solución: archivo XML USER.CONFIG en la carpeta local o roaming del usuario y fuertemente tipado (.Net2).
- Problema: los archivos CONFIG distinguen mayúsculas y minúsculas (no son intuitivas para los humanos), requieren "etiquetas" de apertura / cierre muy específicas, las cadenas de conexión no pueden establecerse 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 agotan 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 Installer para cambiar App.Config durante la instalación y use la configuración de la aplicación como predeterminada si no se encuentra una configuración de usuario.
- Originalmente (WIN3) la configuración se almacenaba 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 ser instalado en una red y compartido por muchas personas.
- Solución (Win311): archivos INI individuales en el directorio de la ventana del usuario.
- Problema: muchas personas pueden compartir una carpeta de Windows, y debe ser de solo lectura de todos modos.
- 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 propia carpeta de datos de aplicación del usuario.
- Problema: es 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. (Lectura / escritura o datos específicos del usuario se mantienen en el registro)