Come faccio a gestire configurazione dell'applicazione in ASP.NET?

Question

Sto avendo difficoltà con la gestione di configurazione di un'applicazione ASP.Net da distribuire per i diversi clienti. Il volume di diverse impostazioni che hanno bisogno giocherellando occupa grandi quantità di tempo, ed i metodi di configurazione attuali sono troppo complicati per permetterci di spingere questa responsabilità ai partner di supporto.

Qualche suggerimento per i metodi migliori per gestire questo o buone fonti di informazione per la ricerca?

Come facciamo le cose allo stato attuale:

• Diversi file di configurazione XML che si fa riferimento nel Web.Config, per esempio un AppSettings.xml.
• Configurazioni per siti specifici sono conservati nei file di configurazione duplicati.
• I file di testo che contengono elenchi di dati specifici al sito
• In alcuni casi, manuali una tantum modifiche al database
• C # di configurazione per Windsor IOC.

Le questioni specifiche che stiamo avendo:

• siti diversi con caratteristiche diverse abilitate, diversi servizi esterni dobbiamo parlare e le diverse regole di business.
• Diversi tipi di distribuzione (dal vivo, prova, formazione)
• chiavi di configurazione cambiano tra versioni (vengono aggiunti, rimuovere), il che significa che dobbiamo aggiornare tutti i file duplicati
• Abbiamo ancora bisogno di essere in grado di alterare le chiavi, mentre l'applicazione è in esecuzione

Le nostre attuali riflessioni su come si potrebbe avvicinarsi a questo sono:

• Spostare la configurazione in codice compilato dinamicamente (possibilmente Boo, Binsor o JavaScript)
• hanno una qualche forma di diffing / fusione di configurazione: combinare una configurazione di default con un / test / config formazione dal vivo e un config site-specific

Answer 1

In qualsiasi modo si va, penso che potrebbe essere utile per avere l'idea di un unico "fonte di verità" per la configurazione.

La duplicazione è bene, se è necessario fornire la configurazione di alcuni componenti nella loro forma specializzata.

Ma per mantenere la vostra sanità mentale Penso che si dovrebbe cercare di puntare ad avere un posto in cui si imposta tutta la configurazione relative alla vostra applicazione, e quindi un meccanismo ben definito per la traduzione che in voci di dentro Web.config, e qualsiasi altra meccanismo di configurazione è necessario supportare.

A seconda del livello di abilità dei vostri partner di supporto (anche se non si romperà XML), immagino si potrebbe anche voler fornire un programma di utilità GUI per far loro volteggiare tutte le manopole in questa "fonte di verità" file di configurazione , con "Applica" andare e l'esecuzione di trasformare il codice / aggiornamento per apportare le modifiche necessarie a Web.config e amici.

Poi per gestire la configurazione per i diversi siti / clienti, si dispone in teoria circa un file di configurazione per la gestione.

Nota: In ASP.NET 4.0 una configurazione di generazione in tempo trasformare il meccanismo sarà disponibile (vedi http://blog.hmobius.com/post/2010/02/17/ASPNET-40-Part-4 -config-Trasformazione-Files.aspx ), che possono rendere questo compito più facile. Sembra è possibile utilizzare questo con alcuni hack per i progetti non web (vedi http://philbolduc.blogspot.com/2010/03/using-config-transforms-outside-web.html ).

Tuttavia, se è necessario apportare queste modifiche in fase di distribuzione, si può essere bloccato con gli strumenti di scrittura personalizzati per fare questo, anche se sembra che le trasformazioni XDT può essere la strada da percorrere per voi, dato che si vuole essere in grado per aggiungere / aggiornare / rimuovere elementi.

Answer 2

Se il codice utilizzando detta elementi di configurazione è il codice di gestire / può cambiare (e tutti in esecuzione nello spazio di codice gestito / C #) vorrei cercare di porting le chiamate di metodo che ottengono le impostazioni per una chiamata in una classe Singleton simile con AT metodo meno un GetString () su di esso.

GetObject () può essere molto utile (controllare la serializzazione XML roba .Net - gli americani incantesimo con una 'z': serializzazione) ... utile per un sacco di roba, ma anche perché significa che si può iniziare il confezionamento correlate elementi di configurazione in voci di singoli nel negozio.

Per quanto riguarda utilizzando un unico negozio (una tabella del database con l'accesso nella cache) o utilizzare la nuova facciata di configurazione solo per incapsulare in cui gli elementi di configurazione sono memorizzati - che sta a voi ... io preferisco fortemente un unico negozio per la distribuzione di prodotti per la configurazione perché poi si sa sempre esattamente dove cercare e dove apportare le modifiche. Tutti i riferimenti dei servizi Web (WCF o altro) possono essere constucted e chiamate utilizzando stringhe di runtime fornito ...:)

In termini di valori di cache per le chiavi - io uso il mio nella cache di memoria (per le applicazioni più piccole), perché il sovraccarico sullo stack è gestibile ... cose come memcache potrebbero lavorare qui (negozio config si accede su TCP / sul rete da qualche parte) ...

EDIT Qualcosa di simile:

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 3

Si può prendere in considerazione guardando script NAnt per l'automazione in combinazione con una qualche utilità .net personalizzato per manipolare le chiavi di configurazione.