¿Cuál de estos u otros métodos (si los hay) prefiere? ¿Por qué?¿Qué método de configuración prefiere en .net? ¿Por qué?
Cuando pares de valores clave no son lo suficientemente utilizo secciones de configuración ya que no son difíciles de usar (a menos que necesite una sección compleja):
Definir su sección personalizada:
public class CustomSection : ConfigurationSection
{
[ConfigurationProperty("LastName", IsRequired = true,
DefaultValue = "TEST")]
public String LastName
{
get { return (String)base["LastName"]; }
set { base["LastName"] = value; }
}
[ConfigurationProperty("FirstName", IsRequired = true, DefaultValue =
"TEST")]
public String FirstName
{
get { return (String)base["FirstName"]; }
set { base["FirstName"] = value; }
}
public CustomSection()
{
}
}
mediante programación crear su sección (si no existe ya):
// Create a custom section.
static void CreateSection()
{
try
{
CustomSection customSection;
// Get the current configuration file.
System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(@"ConfigurationTest.exe");
// Create the section entry
// in the <configSections> and the
// related target section in <configuration>.
if (config.Sections["CustomSection"] == null)
{
customSection = new CustomSection();
config.Sections.Add("CustomSection", customSection);
customSection.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Full);
}
}
catch (ConfigurationErrorsException err)
{
//manage exception - give feedback or whatever
}
}
Siguiendo definición CustomSection y CustomSection real será creado para usted:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="CustomSection" type="ConfigurationTest.CustomSection, ConfigurationTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" allowLocation="true" allowDefinition="Everywhere" allowExeDefinition="MachineToApplication" overrideModeDefault="Allow" restartOnExternalChanges="true" requirePermission="true" />
</configSections>
<CustomSection LastName="TEST" FirstName="TEST" />
</configuration>
Ahora recuperar sus propiedades de la sección:
CustomSection section = (CustomSection)ConfigurationManager.GetSection("CustomSection");
string lastName = section.LastName;
string firstName = section.FirstName;
Si puedo salirse con la suya, solo usaré App.Config, sin embargo, si necesito algo más complejo, usaré secciones de configuración personalizadas. Sí, es difícil entenderlo al principio, pero una fuente de configuración unificada, y una configuración familiar para todos los entornos, vale la pena invertir tiempo, en mi opinión.
Guardo la mayor parte de mi configuración en el contenedor IoC, p. Spring.Net.
Utilizo un archivo de configuración xml personalizado, donde se usa un archivo de configuración diferente para cada entorno (dev/qa/prod). Los archivos de configuración son plantillas que se crean instancias dinámicas con cosas como configuraciones de host/puerto para servicios: esto hace que los entornos múltiples y la conmutación por error sean muy fáciles, ya que el código de creación de instancias de la plantilla puede manejarlo.
Por supuesto, si tiene muy pocas configuraciones y no está interesado en múltiples entornos, entonces app.config es más estándar y es probablemente la mejor manera de hacerlo.
Encuentro NameValueCollectionHandler el más fácil y el mejor, y generalmente me gustaría vincularlo a un archivo de configuración externo mediante el atributo configSource.
Intento poner la configuración ABSOLUTA MÍNIMA en archivos de configuración, con la mayor parte configurada en código con una aplicación que conoce su entorno de despliegue (como por nombre de máquina o dirección IP si lo conoce). Por supuesto, esto requirió mucha más planificación previa y conocimiento de sus entornos, pero mucho menos dolor de cabeza durante la implementación.
Fui administrador de red/sistema en el pasado y ahora desarrollo utilidades internas para aplicaciones de bases de datos. Lo que he encontrado es esto:
Los archivos de configuración simples no anidados son los mejores para las aplicaciones que no cambiarán donde acceden a sus recursos mucho.
Cualquier cosa más compleja debe ir a una base de datos con una interfaz de usuario de administración. Esto solo aplica a usuarios comerciales regulares. Si le preocupa que la base de datos se corrompa, utilice el enfoque de archivo de configuración compleja. Los archivos tienden a corromper menos que las bases de datos.
Ahora, si sus usuarios son otros desarrolladores, entonces tendrá mucha más flexibilidad sobre qué usar para almacenar sus configuraciones.
Si tiene .NET 3.0 disponible, creo que el XamlReader/XamlWriter es muy útil para almacenar configuraciones. Pueden escribir/leer cualquiera.NET objeto de XAML si:
Es especialmente agradable que usted no tiene que decorar sus objetos de configuración con cualquier atributo.
DataSet.WriteXML()/DataSet.ReadXML() funciona bastante bien para mí cuando el app.config no se corte nunca más.
Ponga su configuración en una base de datos. Si ejecuta su aplicación en más de 1 máquina (por ejemplo, una aplicación cliente-servidor), entonces todos los sistemas de configuración por máquina son un PITA. Un área de configuración única es la mejor manera de colocar su configuración. Escribe una guía para manejarlo y estarás muy feliz.
Distribuir archivos de app.config a 200 cuadros de clientes ... no es divertido, especialmente cuando se echa de menos (y lo hacen, créanme).
Parcialmente Yo prefiero usar el archivo XML personalizado y el método de serialización XML para leer y escribir archivos de configuración de esta ... No está restringido a los pares clave/valor y no compleja de implementar ...
que he tenido la buena suerte lanzando mi propia clase especial que devuelve datos de configuración de un archivo ".settings" asociado con el ensamblado que realiza la llamada. El archivo es XML y la clase de configuración lo expone públicamente como un XDocument. Además, el indexador para esta clase de configuración devuelve valores de elementos desde/settings/setting nodes.
Funciona muy bien para aplicaciones simples donde solo necesita un par clave/valor para acceder a la configuración, y funciona muy bien para configuraciones complicadas donde necesita definir su propia estructura y usar System.Xml.Linq para consultar el documento XML.
Otra ventaja de rodar la suya es que puede usar FileSystemWatcher y el tipo de acción de devolución de llamada para iniciar automáticamente un método cuando el archivo cambia en el tiempo de ejecución.
Creo que las configuraciones de clave/valor funcionan bastante bien para archivos de configuraciones simples. Se convierte en un problema cuando el archivo comienza a crecer y es difícil de mantener. Comenzamos a dividir el archivo de configuración en configuraciones de aplicaciones "comunes" y "específicas". El acceso a los archivos es transparente para la aplicación, los valores "comunes" son los mismos en la mayoría de los casos, pero los "específicos" difieren para cada aplicación desplegada.
Utilizo un archivo de configuración xml personalizado. Cada configuración tiene una clave, valor y tipo.
Tiene una sección principal que contiene todas las configuraciones y secciones adicionales que contienen anulaciones de configuración para entornos particulares (desarrollo, montaje, en vivo). Esto no es necesario para reemplazar las secciones del archivo cuando se implementa. Tengo un pequeño contenedor al que puede llamar para obtener una configuración particular o un diccionario que los contenga a todos.
Hace poco creé un T4 template que leerá el archivo de configuración y creará una clase de configuración fuertemente tipada estática. Eso ha sido un gran ahorro de tiempo.
La otra ventaja de usar App.Config es que es el método soportado por el framework para configurar su aplicación. Esto le brinda ventajas tales como tutoriales, documentos API, ayuda externa, etc. –