windows - usar - Archivo de registro frente a INI para almacenar configuraciones de aplicaciones configurables por el usuario
no se ha declarado el elemento configuration (12)
Jeff Atwood tiene un gran artículo sobre el registro de Windows y, en su lugar, es mejor utilizar archivos .INI.
Mi vida sería muchísimo más fácil si las configuraciones por aplicación se almacenaran en un lugar donde pudiera verlas fácilmente, manipularlas y respaldarlas. Como, digamos ... en archivos INI.
- El registro es un punto único de falla . Es por eso que cada sugerencia de edición de registro que pueda encontrar comienza con una gran advertencia grotesca sobre cómo puede romper su computadora con regedit.
- El registro es opaco y binario . Por mucho que no me guste el impuesto de escuadras angulares, al menos los archivos de configuración XML son razonablemente legibles por los humanos, y permiten tantos comentarios como usted considere oportuno.
- El registro debe estar sincronizado con el sistema de archivos . Elimine una aplicación sin "desinstalarla" y se queda con un antiguo error de registro. O si una aplicación tiene un desinstalador mal escrito. El sistema de archivos ya no es la declaración de registro, debe mantenerse sincronizado con el registro de alguna manera. Es una violación total del principio DRY.
- El registro es monolítico . Digamos que quería mover una aplicación a una ruta diferente en su máquina, o incluso a una máquina diferente. Buena suerte extrayendo la configuración relevante para esa aplicación en particular del tarball gigante de registro. Una aplicación determinada generalmente tiene docenas de configuraciones esparcidas por todo el registro.
Soy un nuevo programador de Windows y no estoy seguro de dónde debo almacenar la configuración de la aplicación configurable por el usuario. Entiendo la necesidad de proporcionar un medio fácil de usar para el usuario para cambiar la configuración de la aplicación, como un Editar | Configuración de forma o similar. Pero, ¿dónde debería almacenar los valores después de que el usuario presione el botón Aplicar en ese formulario?
¿Cuáles son los pros y los contras de almacenar configuraciones en el registro de Windows vs. almacenarlas en un archivo INI local o archivo de configuración o similar?
¿Es su aplicación una que está instalada con un programa de instalación, o es solo "Extraer y ejecutar"? En el primer caso, observe los pros y los contras que se detallan aquí. Pero para Extraer y ejecutar, el Registro es en mi opinión un "no-go", ya que las personas esperan poder simplemente eliminar la carpeta de la aplicación para deshacerse de su programa.
Aquí hay una pregunta similar que cubre algunos de los pros y los contras.
Sugeriría no utilizar el registro a menos que su aplicación lo necesite absolutamente. Desde mi entendimiento, Microsoft está tratando de desalentar el uso del registro debido a la flexibilidad de los archivos de configuración. Además, no recomendaría el uso de archivos .ini, sino que usaría algunas de las funciones integradas a .Net para guardar la configuración de usuario / aplicación.
De acuerdo con la documentación de GetPrivateProfileString , debe usar el registro para almacenar información de inicialización.
Sin embargo, al decir eso, si aún desea usar archivos .ini y usa las API de perfil estándar ( GetPrivateProfileString , WritePrivateProfileString y similares) para acceder a ellos, proporcionan formas integradas de proporcionar automáticamente "archivos .ini virtuales". respaldado por el registro. ¡Ganar-ganar!
Como Daniel indicó, el almacenamiento de los datos de configuración en el registro le da la opción de utilizar las plantillas de administración. Es decir, puede definir una Plantilla de administración, usarla en una Política de grupo y administrar la configuración de su aplicación en toda la red. Dependiendo de la naturaleza de la aplicación, esto puede ser una gran bendición.
El registro está optimizado para un acceso rápido y fácil actualización, y es la única manera de hacer ciertas cosas específicas de Windows como asociarse con una extensión. Y puede ignorar el argumento sobre la eliminación de un solo directorio para desinstalar su programa: Windows Vista no le permitirá modificar archivos en el directorio Archivos de programa, por lo que su configuración deberá ir en una carpeta diferente de todos modos.
Hay una guía general para la programación de Windows: haga las cosas de la manera que Microsoft espera que lo haga, y su vida será mucho más fácil.
Dicho esto, puedo ver el atractivo del archivo INI, y no culparía a nadie por considerarlo.
El uso de un archivo ini, en el mismo directorio que la aplicación, permite hacer una copia de seguridad con la aplicación. Entonces, después de volver a cargar su sistema operativo, simplemente restaura el directorio de la aplicación y tiene su configuración de la manera que lo desea.
Pros de archivo de configuración:
- Fácil de hacer. No necesita saber ninguna llamada API de Windows. Solo necesita conocer la interfaz de E / S del archivo de su lenguaje de programación.
- Portátil. Si transfiere su aplicación a otro sistema operativo, no necesita cambiar su formato de configuración.
- Editable por el usuario El usuario puede editar el archivo de configuración fuera de la ejecución del programa.
Pros del registro:
- Seguro. El usuario no puede eliminar accidentalmente el archivo de configuración o dañar los datos a menos que sepa sobre regedit. Y luego el usuario solo está buscando problemas.
- No soy un experto programador de Windows, pero estoy seguro de que al usar el registro es más fácil hacer otras cosas específicas de Windows (configuración específica del usuario, cosas de administración de red como política de grupo o cualquier otra cosa).
Si solo necesita una forma sencilla de almacenar información de configuración, recomendaría un archivo de configuración, utilizando INI o XML como formato. Sugiero usar el registro solo si hay algo específico que desea obtener al usar el registro.
Hay una ventaja más al usar un archivo INI sobre el registro que no he mencionado: si el usuario está utilizando algún tipo de cifrado basado en volumen / archivo, puede obtener el archivo INI para ser cifrado con bastante facilidad. Con el registro, probablemente sea más problemático.
Las respuestas existentes cubren mucho terreno, pero pensé que mencionaría otro punto.
Uso el registro para almacenar la configuración de todo el sistema. Es decir, cuando 2 o más programas necesitan exactamente la misma configuración. En otras palabras, una configuración compartida por varios programas.
En todos los demás casos, utilizo un archivo de configuración local que se encuentra en la misma ruta que el ejecutable o un nivel abajo (en un directorio de configuración). Las razones ya están cubiertas en otras respuestas (portátiles, pueden editarse con un editor de texto, etc.).
¿Por qué poner configuraciones de todo el sistema en el registro? Bueno, descubrí que si se comparte una configuración pero se usan archivos de configuración local, se termina duplicando la configuración. Esto puede significar que termines necesitando cambiar una configuración en múltiples lugares.
Por ejemplo, digamos que el Programa A y el Programa B apuntan a la misma base de datos. Puede tener una configuración de registro "en todo el sistema" para la cadena de conexión. Si desea apuntar a una base de datos diferente, puede cambiar la cadena de conexión en un lugar, y ambos programas se ejecutarán ahora contra la otra base de datos.
Nota: no tiene sentido usar el registro de esta manera si dos o más programas no necesitan usar los mismos valores. Tales como, Programa A y Programa B, ambos necesitan una cadena de conexión de base de datos que puede ser la misma, pero no siempre. Por ejemplo, quiero que el Programa B use ahora una base de datos de prueba, pero el Programa A debe continuar usando una base de datos de producción.
Con el ejemplo anterior, podría tener alguna configuración local que anule la configuración de todo el sistema, pero puede comenzar a complicarse demasiado para tareas simples.
Estoy de acuerdo con Daniel. Si es una aplicación grande, creo que haría cosas en el registro. Si se trata de una aplicación pequeña y desea que el usuario pueda configurar aspectos que no pueden configurarse sin un formulario de configuración, busque un archivo INI rápido.
Normalmente hago el análisis así (si el formato en el archivo .ini es option = value, 1 por línea, comentarios comenzando con #):
static void Parse()
{
StreamReader tr = new StreamReader("config.ini");
string line;
Dictionary<string, string> config = new Dictionary<string, string>();
while ((line = tr.ReadLine()) != null)
{
// Allow for comments and empty lines.
if (line == "" || line.StartsWith("#"))
continue;
string[] kvPair = line.Split(''='');
// Format must be option = value.
if (kvPair.Length != 2)
continue;
// If the option already exists, it''s overwritten.
config[kvPair[0].Trim()] = kvPair[1].Trim();
}
}
Editar: Lo siento, pensé que habías especificado el idioma. La implementación anterior está en C #.
Hay una desventaja para los archivos ini o config y es localizarlos si el usuario tiene la opción de seleccionar dónde está instalado el programa.