Come utilizzare diversi file .settings per i diversi ambienti in .NET?

Question

.NET consente di utilizzare i file .settings per gestire le impostazioni dell'applicazione. Vorrei archiviare produzione, lo sviluppo e le impostazioni di test separatamente in modo che io possa fare qualcosa di simile:

EnvironmentSettings environmentSettings;

// get the current environment (Production, Development or Test)
ApplicationEnvironment Environment = (ApplicationEnvironment)
    Enum.Parse(typeof(ApplicationEnvironment), Settings.Default.ApplicationEnvironment);

switch (Environment)
{
    case ApplicationEnvironment.Production:
        environmentSettings = Settings.Production;
        break;
    ...
}

string reportOutputLocation = environmentSettings.ReportOutputLocation;

In sostanza, voglio due classi distinte Regolazioni: la classe delle impostazioni generali che memorizza le proprietà specifiche ambiente selezionato e non l'ambiente, e 3 le istanze statiche di una seconda classe chiamata EnvironmentSettings. L'esempio utilizzato dovrebbe dipendere dall'ambiente specificato nella classe Impostazioni generale.

Esiste un modo per fare questo corto di impostare manualmente i valori per tutte queste impostazioni in un costruttore statico o qualcosa del genere? Se devo farlo, preferirei avere solo una classe di grandi Impostazioni con immobili come "DevOutputLocation", "LiveOutputLocation", ecc.

posso avere più file .settings nel mio progetto, ma che solo crea classi separate che non derivano le une dalle altre. Così ho potuto fare DevelopmentSettings.settings, ProductionSettings.settings e file TestSettings.settings e dare loro le stesse proprietà, ma poi avrei bisogno di un po 'di istruzioni switch in tutto il mondo per determinare quale classe da utilizzare perché non derivano da una classe comune .

Answer 1

Sto usando questo approccio per .config file, sono sicuro che vi aiuterà anche voi. Basta guardare su post sul blog di Scott Hanselman e this . L'ideologia è semplice come l'inferno, ma funziona abbastanza bene. Tutto quello che vi serve è:

1. crea diversi file di configurazioni differenti
2. nome loro per convenzione, ad esempio my.dev.settings, my.live.settings
3. creare post evento build (vedi link)
4. godere =)

Codice di istanze per voi di classe con le impostazioni sarà sempre guardare nelle impostazioni di default (che sarà sostituito dopo ogni generazione con il necessario uno), quindi questo approccio richiede il minimo sforzo.

Answer 2

Un pensiero è che il passaggio tra una serie di valori statici suona come un modo piuttosto irto di fare le cose. Vorrei suggerire guardando il pattern Singleton. Questo modello fornisce un'istanza singola classe che viene condiviso tra tutti i riferimenti alla classe, ma quando è caricato la prima volta si può fare il vostro normale bit di inizializzazione per controllare il proprio ambiente e impostare i valori di conseguenza.

Allo stesso modo, piuttosto che utilizzare gli interruttori di agire su classi diverse, sarebbe non essere alla ricerca a progettare un'interfaccia, e avere ogni classe implementa l'interfaccia?

Answer 3

C'è un po 'di overhead coinvolto nel fare un controllo per determinare quale ambiente è in esecuzione. Se si sta parlando di un ambiente web, allora questo potrebbe significare un significativo calo di prestazioni. Vorrei raccomandare la creazione di tre file di configurazione separati e la creazione di un sistema di integrazione e la distribuzione continua che gestisce la denominazione e roll-out del file di impostazioni appropriate in base all'ambiente. Nel tuo caso si avrebbe tre file, Production.config, Development.config e Test.config. Il server di integrazione sarebbe quindi creare una copia di questo file per web.config o app.config in base all'ambiente.

Per quanto riguarda alcuna manutenzione aggiuntiva coinvolti con il mantenimento di tre file separati ogni volta che viene effettuata una modifica alla configurazione, teniamo i file auto-formattato e usare qualcosa come WinMerge per vedere facilmente le differenze e tenerli in una corretta sincronizzazione. Questo tipo di file in genere non richiedono molti cambiamenti e quando lo fanno di solito sono aggiunte minori.

Answer 4

Io attualmente faccio qualcosa di simile alla soluzione di cui parla pdavis. Ma alla semplificazione più file di configurazione che uso a modelli T4 per creare i file di configurazione specifici dell'ambiente. In questo modo v'è un unico file web.tt che gestisce la generazione del file predefinito web.config. Ogni ambiente ha un proprio file di modello (qa.tt, production.tt, ecc) che eredita da web.tt e contiene tutte le sostituzioni specifiche ambientali. Eventuali modifiche alle web config -. Nuove impostazioni di app, le impostazioni di configurazione, ecc vengono propagate automaticamente a tutti i file di configurazione specifica regione rigenerando i modelli, e non si devono preoccuparsi di mantenere i file sincronizzati utilizzando uno strumento diff

Answer 5

Solo un'idea, ma potrebbe funzionare ...

• È necessario + 2 file di impostazioni N (N diverse build; 2 master) con contenente gli stessi tasti.

• Cancella il "strumento personalizzato" proprietà per tutti loro, ma uno dei maestri (così un solo la master genera).

• Modificare lo script pre-compilazione per ogni release per copiare il file delle impostazioni appropriate contenuti nel file di build-master.

• Modificare lo script di post-generazione per copiare il contenuto del file master secondario torna al file master originale.

Nota: Se si riesce a lavorare con il fornitore di controllo del codice sorgente nel pre e post-script di compilazione, non hai bisogno di un master secondario - si può solo check-out la pre-compilazione e annullare check-out la post-generazione. Tuttavia, questo può causare problemi in un ambiente di integrazione continua dal momento che un file bloccato richiederebbe la costruzione di fallire.

Inoltre ho mai fatto; anche se ci sono momenti avrei voluto ci fosse un modo più up-front di fare qualcosa di simile in VS.

Answer 6

Proprio qualche info in più su .NET ambiente basato file di configurazione senza utilizzare il sopra implementazione particolare:

La Biblioteca Enterprise ha questa caratteristica dal V3.0: Sommario

Visual Studio 2010 avrà anche questa funzione. La sua chiamata Config Trasformazione