Mejores prácticas del Registro de Windows

Question

¿De qué manera se supone que se utilizará el registro de Windows? Sé que está bien almacenar una pequeña cantidad de preferencias de los usuarios, pero ¿se considera una mala práctica almacenar allí todos los datos de los usuarios? Creo que dependería del conjunto de datos, entonces, ¿qué tal si se trata de pequeñas cantidades de datos, por ejemplo, menos de 2 KB, en aproximadamente 100 pares clave/valor diferentes? ¿Es esta mala práctica? ¿Un archivo plano o SQLite db sería una mejor práctica?

Answer 1

Para mí, los elementos simples de configuración de usuario y los datos de usuario se almacenan mejor en un archivo de configuración XML simple, un archivo SQLbite SQLLite o un MS SQL Server Compact db. El medio de almacenamiento exacto depende de los detalles de la implementación.

Solo uso el registro para cosas que necesito configurar con poca frecuencia y que los usuarios no necesitan para poder cambiar/ver. Por ejemplo, he almacenado información de licencia cifrada en el registro antes para evitar la eliminación accidental de los datos por parte del usuario.

Answer 2

Creo que Microsoft recomienda el uso de almacenamiento aislado en lugar del registro de Windows.

Here's un artículo que explica cómo usarlo en .Net.

Puede encontrar esos archivos en Windows XP en Documentos & Configuración \\ Configuración local \ Datos de la aplicación \ Almacenamiento aislado. Los datos están en archivos .dat

Answer 3

Como cada usuario tiene un espacio de directorio en Windows que ya está dedicado a almacenar datos de usuario de la aplicación, lo uso para almacenar los datos de nivel de usuario (preferencias, por ejemplo) allí.

En C#, lo conseguiría haciendo algo como esto:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); 

Por lo general, voy a almacenar archivos SQLite allí o lo que sea apropiado para la aplicación.

Answer 4

El uso del registro para almacenar datos tiene principalmente un problema: no es muy fácil de usar. Los usuarios no tienen prácticamente ninguna posibilidad de realizar una copia de seguridad de su configuración, copiarla en otra computadora, solucionarla (o restablecerla) si se corrompe, o generalmente solo ver qué está haciendo su software.

Mi regla de oro es usar el registro solo para comunicarme con el sistema operativo. Asociaciones de tipo de archivo, entradas de desinstalador, procesos para ejecutar al inicio, esas cosas, obviamente, tienen que estar en el registro.

Pero los datos que se utilizan en su aplicación solo pertenecen a un archivo de la carpeta de datos de la aplicación. (cualquiera de las 3+ carpetas de datos de aplicaciones que Microsoft actualmente quiere que uses, de todos modos)

Answer 5

Para mí, parece más fácil pensar en lo que NO debes poner allí. por ejemplo: datos dinámicos, como el "último archivo abierto" del editor y las opciones del proyecto. Es realmente molesto cuando su aplicación pierde sincronización con el registro (eliminación de archivos, bloqueo del sistema, etc.) y recupera información que ya no es válida, posiblemente bloqueando al usuario.

En un trabajo anterior, vi a un chico que almacenaba un porcentaje de completitud de transferencia de datos, escribiendo los nuevos valores cada 10k y teniendo la GUI recuperando este valor cada segundo para que se muestre en la barra de título.

Answer 6

I diferenciaría:

Por un lado hay aplicación de datos de configuración específica que se necesita para la aplicación a ejecutar, por ejemplo,Direcciones IP a las que conectarse, qué carpetas usar para qué tipo de archivos, etc., y configuraciones no triviales por usuario. Aquellos que pongo en un archivo de configuración, en formato i para cosas simples, xml si se vuelve más complejo.

Por otro lado, hay configuraciones triviales por usuario (mejor ejemplo: posiciones de ventanas y diseño). Para evitar saturar los archivos de configuración (que algunos usuarios querrán editar por sí mismos, por lo que pocas entradas claramente ordenadas son obligatorias), me gusta ponerlas en el registro (con valores predeterminados conservadores establecidos en la aplicación si no hay ajustes en el registro) puede ser encontrado).

Lo hago principalmente como istmatt sais: Guardo los archivos de configuración dentro de la carpeta %APPDATA%. Por lo general, en %APPDATA%\ApplicationName, no me gusta el valor predeterminado de .NET de APPDATA%\CompanyName\ApplicationName\Version, ese nivel de detalle y complejidad es contraproducente para la mayoría de las aplicaciones de tamaño pequeño a mediano.

No estoy de acuerdo con el ejemplo de Marcelo MD de no almacenar archivos recientemente utilizados en el registro. IMO es exactamente el tipo volátil de información específica del usuario que se puede almacenar allí. (Su ejemplo de lo que noque hacer es muy buena, sin embargo!)

Answer 7

Si la aplicación va a ser desplegado "en la empresa", tenga en cuenta que los administradores pueden modificar el registro usando herramientas de directiva de grupo. Por ejemplo, si firefox usó el registro para cosas como el servidor proxy, haría la implementación muy fácil porque un administrador puede usar las herramientas estándar en el directorio activo para configurarlo. Si usas cualquier otra cosa, no creo que se puedan hacer tan fácilmente.

Así que no descarte el registro todos juntos. Si existe la posibilidad de que un administrador quiera estandarizar partes de su configuración en una red, coloque la configuración en el registro.

Answer 8

Voy a tomar una vista contraria.

El registro es un buen lugar para poner datos de configuración de todo tipo. En general, es más rápido que la mayoría de los archivos de configuración y más confiable (transacciones individuales en el registro se procesan, por lo que si la aplicación falla durante una escritura, el registro no está dañado; en general, no es el caso con los archivos ini).

Marcelo MD tiene toda la razón: almacenar cosas como el porcentaje de operación completo en el registro (o cualquier otro almacenamiento no volátil) es una idea horrible. Por otro lado, almacenar datos como los archivos usados ​​más recientemente está bien, el registro fue creado para ese tipo de problema.

Varios de los comentaristas en esta publicación que hablan de la lista de MRU han discutido el problema de lo que sucede cuando la lista de MRU no se sincroniza debido a bloqueos de la aplicación. Me pregunto por qué es mejor guardar la lista de MRU en un archivo plano en el almacenamiento por usuario.

Tampoco estoy seguro de cuáles son las "implicaciones de seguridad" de almacenar sus datos en el registro. El registro es tan seguro como el sistema de archivos: el registro y el sistema de archivos utilizan el mismo mecanismo de ACL para proteger sus datos.

Si va a almacenar sus datos de usuario en un archivo, debe poner absolutamente sus datos en% APPDATA% \ CompanyName \ ApplicationName al menos, de esa manera si dos desarrolladores diferentes crean una aplicación con el mismo nombre (cuántos Las aplicaciones de "Administrador de medios" están ahí fuera?) No tendrá colisiones.