2010-03-19 9 views
9

Estoy revisando un proyecto .NET, y me encontré con un uso bastante pesado de los archivos .ini para la configuración. Preferiría usar archivos app.config en su lugar, pero antes de saltar y resolver un problema con los desarrolladores, me pregunto si hay algún motivo válido para favorecer a los archivos .ini sobre app.config.Archivos App.config vs. .ini

+2

Raymond Chen tiene un artículo interesante sobre las diferencias entre la configuración de ini y xml, y por qué ini fue originalmente obsoleta a favor del registro. Ver - http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx –

+1

Gracias por el enlace, es una lectura interesante. ¡Y el proyecto mencionado también usa el registro para obtener información sobre licencias! La configuración está por todos lados. :) –

+0

Nadie ha indicado nada acerca de la persistencia de la configuración durante las reinstalaciones/para diferentes usuarios, etc. Se debe señalar que el archivo app.config está vinculado a la aplicación y a menos que usted maneje esto específicamente cuando instalación/actualización, etc., puede perder todas sus configuraciones !!Los archivos Ini/xml pueden permanecer intactos aquí – Simon

Respuesta

6

Bueno, en promedio, los archivos .INI son probablemente más compactos y de alguna manera más legibles para los humanos. XML es un poco difícil de leer, y es bastante detallado.

Sin embargo, app.config por supuesto es el mecanismo de configuración .NET estándar que es compatible con .NET y tiene muchos ganchos y formas de hacer las cosas. Si vas con archivos .INI, básicamente estás "rodando por ti mismo todo el camino". Caso clásico de "reinventar la rueda".

Por otra parte, ¿hay alguna posibilidad de que este sea un proyecto que comenzó su vida antes de .NET? ¿O un puerto de una aplicación de Windows pre.NET existente donde los archivos .INI eran el camino a seguir?

No hay nada intrínsecamente incorrecto con los archivos .INI. Creo que ya no están realmente soportados en .NET, y usted está solo para extenderlos, manejarlos, etc. Y ciertamente es un "stumper" si alguna vez necesita traer ayuda externa a bordo, casi ningún desarrollador .NET habrá estado expuesto a archivos .INI mientras que el sistema de configuración .NET es bastante conocido y entendido.

+1

El proyecto es relativamente nuevo, pero los archivos .ini parecen ser malos habits que han sido transferidos por algunos desarrolladores de proyectos anteriores. Y sí, es un caso clásico de reinvención de ruedas. :) No estoy seguro de estar de acuerdo con que .ini sea más legible por humanos. Con archivos .config, VS y edición intellisense es muy fácil. Y me gustaría que el equipo cree un buen esquema para admitir las configuraciones. Gracias por su respuesta. –

+0

OK, entonces si solo es un mal hábito, trataría de cambiar eso :-) Intentaré establecer por qué app.config es superior -un mejor soporte en .NET, capacidad para escribir grupos de secciones forzadas con esquemas XML, etc.- y eso ¡con suerte será la patada en el trasero para que ciertos desarrolladores deban finalmente darse por vencidos con la tecnología de hace más de 10 años y llegar a algo más nuevo! –

1

Personalmente nunca archivos ini usuario/xml de configuración a algo más que cargar todos los valores en un conjunto unitario o algo y luego usarlos como este ... runtime

Dicho esto creo firmemente que se debe hacer mira el tipo de datos y el uso de datos. Si los datos están en el contexto de la aplicación en términos de configuraciones y configuraciones, entonces creo que el archivo app.config es el lugar correcto para mantener esta configuración.

Si, por otro lado, los datos están relacionados con la carga de proyectos, imágenes u otros recursos relacionados con el contenido de la aplicación, entonces creo que el .ini (¿alguien más usa archivos .ini? Estoy pensando en un archivo .xml para almacenar esta información). En resumen: segmente el contenido de los datos que se almacenan según el dominio y el contexto.

3

Los archivos Ini están bastante bien en mi libro. El problema es GetPrivateProfileString() y primos. Appcompat lo ha convertido en un feo mutt de una función API. Recuperar un solo valor de ini lleva unos 50 milisegundos, eso es una montaña de tiempo en una PC moderna.

Pero el mayor problema es que no puede controlar la codificación del archivo INI. Windows siempre usará la página de códigos del sistema para interpretar cadenas. Lo cual está bien siempre y cuando su programa no viaje lejos de su escritorio. Si lo hace, tiene un serio riesgo de producir galimatías cuando no restringe el conjunto de caracteres utilizado en su archivo INI a ASCII.

XML no tiene este problema, es bien compatible con .NET Framework. Ya sea mediante el uso de configuraciones o la gestión de su configuración usted mismo.

Cuestiones relacionadas