¿Cómo administro la configuración de la aplicación en ASP.NET?

Question

Tengo dificultades para administrar la configuración de una aplicación ASP.Net para implementar para diferentes clientes. El gran volumen de configuraciones diferentes que requieren manipulación requiere grandes cantidades de tiempo, y los métodos de configuración actuales son demasiado complicados para permitirnos llevar esta responsabilidad a los socios de soporte.

¿Alguna sugerencia para mejores métodos para manejar esta o buenas fuentes de información para investigar?

cómo hacemos las cosas por el momento:

• Varios archivos de configuración XML que se hace referencia en Web.Config, por ejemplo, un AppSettings.xml.
• Las configuraciones para sitios específicos se guardan en archivos de configuración duplicados.
• Los archivos de texto que contienen listas de datos específicos al sitio
• En algunos casos, los cambios de una sola vez a la base de datos manuales
• C# configuración de Windsor COI.

Los temas específicos que estamos teniendo:

• diferentes sitios con diferentes características habilitadas, diferentes servicios externos que tenemos que hablar y diferentes reglas de negocio.
• Diferentes tipos de implementación (en vivo, prueba, capacitación)
• teclas de configuración cambian entre versiones (se añaden, eliminar), lo que significa que tenemos que actualizar todos los archivos duplicados
• Todavía tenemos que ser capaces de alterar teclas mientras se ejecuta la aplicación

nuestro pensamiento actual sobre cómo podemos abordar esto son:

• Mover la configuración en código compilado de forma dinámica (posiblemente Boo, Binsor o JavaScript)
• tienen alguna forma de diffing/fusión de configuración: combinar una configuración por defecto con una prueba/config en vivo/formación y una configuración específica del sitio

Answer 1

Si el código que usa dicha elementos de configuración es el código a manejar/puede cambiar (y todos ejecutando en el espacio de código administrado/C#) Me gustaría portar las llamadas al método que obtienen la configuración de una llamada en una clase de tipo singleton con al menos un método GetString() en él.

GetObject() puede ser muy útil (consulte la serialización de .Net XML, los estadounidenses lo deletrean con una 'z': serialización) ... útil para muchas cosas pero también porque puede comenzar a empaquetar elementos de configuración relacionados en entradas individuales en la tienda.

En cuanto a usar una única tienda (una tabla de base de datos con acceso en caché) o usar su nueva fachada de configuración solo para encapsular dónde están almacenados los elementos de configuración, depende de usted ... Prefiero una única tienda por despliegue de producto para la configuración porque entonces siempre se sabe exactamente dónde buscar y dónde hacer cambios. Todas las referencias del servicio web (WCF o de otro tipo) se pueden construir y llamar utilizando cadenas proporcionadas por el tiempo de ejecución ...:)

En términos de valores de almacenamiento en caché para claves: uso el mío en memoria caché (para aplicaciones más pequeñas) porque la sobrecarga en la pila es manejable ... cosas como Memcache podrían funcionar aquí (se accede a config store a través de TCP/en la red en alguna parte) ...

EDITAR Algo así como:

public class ConfigurationStore 
{ 
    private static ConfigurationStore _instance = null; 

    public static ConfigurationStore Instance { 
     get { 
     if(_instance == null) 
     { 
      _instance = new ConfigurationStore(); 
     } 

     return _instance; 
     } 
    } 

    public string GetValue(string key) 
    { 
     .... 
    } 

    public Object GetObject(string key) 
    { 
     ... 
    } 
} 

Answer 2

Es posible considerar la búsqueda de secuencias de comandos para la automatización NAnt combinado con alguna utilidad .net costumbre de manipular las teclas de configuración.

Answer 3

Cualquiera que sea el camino que tome, creo que podría ser valioso tener la noción de una única "fuente de verdad" para su configuración.

La duplicación está bien, si necesita proporcionar la configuración de algunos componentes en su propia forma especializada.

Pero para conservar la cordura, creo que debería tratar de tener un lugar donde establezca toda la configuración correspondiente a su aplicación, y luego un mecanismo bien definido para traducir eso en entradas dentro de Web.config, y cualquier otro mecanismo de configuración que tienes que admitir.

Dependiendo del nivel de habilidad de sus socios de soporte (ya sea que rompan o no XML), me imagino que también podría querer proporcionar una utilidad de GUI para dejarlos girar todas las perillas en esta configuración de "fuente de verdad" archivo, con "Aplicar" yendo y ejecutando el código de transformación/actualización para realizar los cambios necesarios en Web.config & amigos.

Luego, para administrar su configuración para diferentes sitios/clientes, en teoría tiene alrededor de un archivo de configuración para administrar.

Nota: En ASP.NET 4.0, habrá disponible un mecanismo de transformación de configuración de tiempo de compilación (consulte http://blog.hmobius.com/post/2010/02/17/ASPNET-40-Part-4-Config-Transformation-Files.aspx), que puede facilitar esta tarea. Parece que puede usar esto con algunos hacks para proyectos que no sean web (consulte http://philbolduc.blogspot.com/2010/03/using-config-transforms-outside-web.html).

Sin embargo, si necesita hacer estos cambios en el momento del despliegue, puede que tenga que escribir herramientas personalizadas para hacerlo, aunque parece que las transformaciones XDT pueden ser el camino a seguir, dado que desea estar capaz de agregar/actualizar/eliminar elementos.