Registro vs.Archivo INI para almacenar configuraciones de aplicaciones configurables por el usuario

StackOverflow https://stackoverflow.com/questions/6607

Pregunta

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 que el usuario cambie la configuración de la aplicación, como una edición | Formulario de configuración o similar.Pero, ¿dónde debo almacenar los valores después de que el usuario presione el botón Aplicar en ese formulario?

¿Cuáles son las ventajas y desventajas de almacenar la configuración en el registro de Windows vs.¿almacenarlos en un archivo INI local o un archivo de configuración o similar?

¿Fue útil?

Solución

Ventajas del archivo de configuración:

  1. Fácil de hacer.No es necesario conocer ninguna llamada a la API de Windows.Sólo necesita conocer la interfaz de E/S de archivos de su lenguaje de programación.
  2. Portátil.Si traslada su aplicación a otro sistema operativo, no necesita cambiar el formato de configuración.
  3. Editable por el usuario.El usuario puede editar el archivo de configuración fuera del programa en ejecución.

Ventajas del registro:

  1. Seguro.El usuario no puede eliminar accidentalmente el archivo de configuración ni dañar los datos a menos que conozca regedit.Y entonces el usuario simplemente busca problemas.
  2. No soy un programador experto en Windows, pero estoy seguro de que usar el registro facilita otras cosas específicas de Windows (configuraciones específicas del usuario, cuestiones de administración de red como políticas de grupo o cualquier otra cosa).

Si sólo necesita una forma sencilla de almacenar información de configuración, le recomendaría un archivo de configuración, utilizando INI o XML como formato.Sugiero usar el registro sólo si hay algo específico que desea evitar al usar el registro.

Otros consejos

Jeff Atwood tiene una gran artículo sobre el registro de Windows y por qué es mejor utilizar archivos .INI.

Mi vida sería muchísimo más fácil si las configuraciones de cada aplicación se almacenaran en un lugar donde pudiera verlas, manipularlas y hacer copias de seguridad fácilmente.Como, digamos...en archivos INI.

  • El registro es un punto único de fallo.Es por eso que cada consejo de edición de registro que encontrará comienza con un gran descargo de responsabilidad sobre cómo puede dañar su computadora con regedit.
  • El registro es opaco y binario.Por mucho que no me guste el impuesto sobre los corchetes angulares, al menos los archivos de configuración XML son razonablemente legibles por humanos y permiten tantos comentarios como crea conveniente.
  • El registro tiene que ser en sincronización con el sistema de archivos.Elimine una aplicación sin "desinstalarla" y quedará con un registro obsoleto.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 desea mover una aplicación a una ruta diferente en su máquina, o incluso a una máquina completamente diferente.Buena suerte extrayendo la configuración relevante para esa aplicación en particular del archivo tarball de registro gigante.Una aplicación determinada suele tener docenas de configuraciones repartidas por todo el registro.

Según la documentación de Obtener cadena de perfil privado, debe utilizar el registro para almacenar información de inicialización.

Sin embargo, dicho esto, si aún desea utilizar archivos .ini y utilizar las API de perfil estándar (GetPrivateProfileString, WritePrivateProfileString, y similares) para acceder a ellos, proporcionan formas integradas de proporcionar automáticamente "archivos .ini virtuales" respaldados por el registro.¡Todos ganan!

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

Sugeriría no utilizar el registro a menos que su aplicación lo necesite absolutamente.Según tengo entendido, Microsoft está tratando de desalentar el uso del registro debido a la flexibilidad de los archivos de configuración.Además, no recomendaría usar archivos .ini, sino algunos de los funcionalidad incorporada a .Net para guardar la configuración del usuario/aplicación.

El uso de un archivo ini, en el mismo directorio que la aplicación, permite realizar una copia de seguridad con la aplicación.Entonces, después de recargar su sistema operativo, simplemente restaure el directorio de la aplicación y tendrá la configuración como la desea.

Hay una ventaja más de usar un archivo INI sobre el registro que no he visto mencionada:Si el usuario está utilizando algún tipo de cifrado basado en volumen/archivo, puede cifrar el archivo INI con bastante facilidad.Con el registro probablemente será más problemático.

Como indicó Daniel, almacenar datos de configuración en el registro le brinda la opción de utilizar 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 de gran ayuda.

Estoy de acuerdo con Daniel.Si se trata de una aplicación grande, creo que haría cosas en el registro.Si es una aplicación pequeña y desea que el usuario pueda configurar aspectos de ella sin crear un formulario de configuración, opte por un archivo INI rápido.

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

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

El registro está optimizado para un acceso rápido y una actualización sencilla, y es la única forma de hacer ciertas cosas específicas de Windows, como asociarse con una extensión.Y puede ignorar el argumento sobre eliminar 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 a una carpeta diferente de todos modos.

Hay una guía general para la programación de Windows: haga las cosas como Microsoft espera que las haga y su vida será mucho más fácil.

Dicho esto, veo el atractivo del expediente INI y no culparía a nadie por considerarlo.

Las respuestas existentes cubren mucho terreno, pero pensé en mencionar otro punto.

Utilizo el registro para almacenar configuraciones de todo el sistema.Es decir, cuando 2 o más programas necesitan exactamente la misma configuración.Es decir, un escenario compartido por varios programas.

En todos los demás casos, uso un archivo de configuración local que se encuentra en la misma ruta que el ejecutable o en un nivel inferior (en un directorio de configuración).Los motivos ya están cubiertos en otras respuestas (portátil, se puede editar 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 usas archivos de configuración locales, terminas duplicando la configuración.Esto puede significar que termines necesitando cambiar una configuración en varios 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 "para 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 en 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 necesitan una cadena de conexión a la base de datos que puede ser el mismo, pero no siempre.Por ejemplo, quiero que el Programa B utilice ahora una base de datos de prueba, pero el Programa A debería seguir utilizando una base de datos de producción.

Con el ejemplo anterior, es posible que algunas configuraciones locales anulen las configuraciones de todo el sistema, pero puede comenzar a volverse demasiado complicado para tareas simples.

Hay un inconveniente de los archivos ini o de configuración y es localizarlos si el usuario tiene la opción de seleccionar dónde está instalado el programa.

¿Su aplicación se instala con un programa de instalación o es simplemente "Extraer y ejecutar"?En el primer caso, observe los pros y los contras que se describen aquí.Pero para Extraer y ejecutar, el Registro es, en mi opinión, "prohibido", ya que la gente espera poder simplemente eliminar la carpeta de la aplicación para deshacerse de su programa.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top