Archivo de registro frente a INI para almacenar configuraciones de aplicaciones configurables por el usuario

Question

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?

Answer 1

Pros de archivo de configuración:

1. 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.
2. Portátil. Si transfiere su aplicación a otro sistema operativo, no necesita cambiar su formato de configuración.
3. Editable por el usuario. El usuario puede editar el archivo de configuración fuera de la ejecución del programa.

Pros de registro:

1. 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.
2. No soy un programador de Windows experto, 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 lo que sea).

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.

Answer 2

De acuerdo con la documentación para GetPrivateProfileString, debe usar el registro para almacenar la información de inicialización.

Sin embargo, si desea utilizar archivos .ini y utiliza las API de perfil estándar (GetPrivateProfileString, WritePrivateProfileString y similares) para acceder a ellas, proporcionan formas integradas de proporcionar automáticamente "virtual archivos .ini "respaldados por el registro. ¡Ganar-ganar!

Answer 3

Hay una pregunta similar here que cubre algunos de los pros y los contras.

Sugeriría no utilizar el registro a menos que su aplicación lo necesite. 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 algunos de los built-in functionality a .Net para guardar las configuraciones de usuario/aplicación.

Answer 4

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 se pueden configurar sin realizar un formulario de configuración, busque un archivo INI rápido.

Normalmente hago el análisis así (si el formato está en.ini es opción = valor, 1 por línea, los comentarios comienzan 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(); 
    } 
} 

Edit: Lo siento, pensé que había especificado el idioma. La implementación anterior está en C#.

Answer 5

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

Answer 6

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.

Answer 7

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, pueden obtener el archivo INI cifrado con bastante facilidad . Con el registro, probablemente sea más problemático.

Answer 8

Jeff Atwood tiene un gran article sobre el registro de Windows y por qué es mejor utilizar archivos .INI en su lugar.

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 hacer una copia de seguridad de ellas. 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 tiene que ser en sincronización 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.

Answer 9

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 la asociación 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.

Answer 10

El uso de un archivo ini, en el mismo directorio que la aplicación, hace posible realizar 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.

Answer 11

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

Answer 12

Las respuestas existentes cubren mucho terreno, pero pensé que mencionaría otro punto.

Utilizo 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 hacia 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 la configuración 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 utilizar el registro de esta manera si dos o más programas no necesitan utilizar los mismos valores. Por ejemplo, el Programa A y el Programa B, que necesitan una cadena de conexión de base de datos que pueden, pueden ser iguales, 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, puede hacer que algunas configuraciones locales anulen la configuración de todo el sistema, pero puede empezar a complicarse demasiado para tareas simples.