2009-05-04 23 views
7

Tengo una solución que incluye tanto una aplicación web como una aplicación de servicio de Windows NT. Estos son, por supuesto, dos proyectos diferentes pero dentro de la misma solución. Sin embargo, comparten una gran cantidad de la misma configuración.Archivos de configuración compartidos en .NET

Actualmente tengo los mismos valores tanto en el archivo web.config como en el archivo app.config. Esto está empezando a complicarse y me gustaría tener un archivo de configuración compartido para las dos aplicaciones dentro de la solución.

  • ¿Hay un problema para la aplicación web si la configuración no está al nivel de la raíz de la aplicación web ? ¿Hay limitaciones aquí?
  • Voy a perder la memoria caché y reciclaje automático de la aplicación web si yo no uso web.config
  • Es generalmente una mala idea para compartir la configuración como se describe?

Respuesta

9

Bueno, podría "externalizar" ciertas partes de las configuraciones en archivos .config separados, y usarlos desde ambos lugares.

E.g. usted podría externalizar la configuración de cadena de conexión de este modo:

<connectionStrings configSource="connectionStrings.config" /> 

y luego tener el archivo "connectionString.config" de esta manera:

<?xml version="1.0" encoding="utf-8"?> 
<connectionStrings> 
    <add name="ConfigurationDatabase" 
     connectionString="server=.;Integrated Security=true;database=test"/> 
    <add name="TestDatabase" 
     connectionString="server=TEST;Integrated Security=true;database=test"/> 
</connectionStrings> 

Básicamente, cualquier ConfigurationSection tiene un entorno "configSource", el cual le permite especificar un archivo externo para usar.

De esta manera, es posible que pueda compartir partes comunes de los dos archivos de configuración.

Marc

+0

El atributo configSource no le permite poner ".." o "~ /" en él y dice "Debe hacer referencia a un archivo en el mismo directorio o en un subdirectorio como el archivo de configuración". Dado esto, ¿cómo pueden dos proyectos compartir un archivo externo si ninguno puede llegar a un nivel de directorio más alto que él? –

+0

@James en Indy: puede utilizar la funcionalidad de nivel de sistema de archivos NTFS, como los enlaces duros y blandos, que pueden hacer que un archivo aparezca en un directorio, aunque no esté realmente allí ... (es solo un enlace/puntero al archivo real). Google para "enlace duro NTFS" o "puntos de unión NTFS" –

2

todavía tendrá un .config web, ya que hay elementos de la configuración que son específicas web que no estará en el app.config de su servicio. Como Marc says, usar el atributo ConfigSource le permitirá compartir elementos comunes.

Tenga en cuenta que el elemento appSettings tiene una pequeña diferencia: el atributo Archivo.

Especifica una ruta de acceso relativa a un archivo externo que contiene configuraciones de aplicación personalizadas. El archivo especificado contiene el mismo tipo de configuración que se especifica en appSettings para agregar, borrar y eliminar atributos, y usa el mismo formato de par clave/valor que esos elementos.

Esto comporta de manera diferente al atributo configSource, ya que no tiene que reemplazar toda la sección con el archivo externo, puede simplemente contener elementos que desea tener, además, o para anular los valores:

puede utilizar el atributo de archivo para especificar un archivo de configuración que ofrece ajustes adicionales o prioridad sobre el valor que se especifican en el elemento appsettings.

Si está utilizando ConfigSource compartir otros elementos, entonces usted todavía tendrá reinicios automáticos de la aplicación cuando se cambian los valores - la nota sobre los restartOnExternalChanges atributo debe ser ignorado para las aplicaciones ASP.NET, sin embargo, utilizando el archivo atributo significará que los cambios no provocarán un reinicio.

El contenido de los archivos externos aún debe almacenarse en caché, por lo que el rendimiento no debe verse afectado.

Cuestiones relacionadas