Come utilizzare diversi file .settings per 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; 

Fondamentalmente, io voglio due classi impostazioni separate: la classe impostazioni generali che memorizza l'ambiente selezionato e non - proprietà specifiche dell'ambiente e 3 istanze statiche di una seconda classe denominata EnvironmentSettings. L'istanza utilizzata dovrebbe dipendere dall'ambiente specificato nella classe Impostazioni generali.

C'è un modo per fare questo a meno di impostare manualmente i valori per tutte queste impostazioni in un costruttore statico o qualcosa del genere? Se devo farlo, preferirei avere solo una grande classe Settings con proprietà come "DevOutputLocation", "LiveOutputLocation", ecc.

Posso avere più file .settings nel mio progetto ma solo creare classi separate che non derivano l'uno dall'altro. Quindi potrei creare i file DevelopmentSettings.settings, ProductionSettings.settings e TestSettings.settings e dare loro le stesse proprietà, ma poi avrei bisogno di una serie di istruzioni switch ovunque per determinare quale classe usare perché non deriva da una classe comune .

Answer 1

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

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

la creazione di istanze per voi di classe con le impostazioni sarà sempre guardare nelle impostazioni di default (che sarà essere sostituito dopo ogni costruzione con quello necessario), quindi questo approccio richiede uno sforzo minimo.

Answer 2

Solo un'idea, ma potrebbe funzionare ...

• Avrete bisogno di N + 2 file di impostazioni (N diverse corporature, 2 master) con contenente gli stessi tasti.

• Cancellare la proprietà "Strumento personalizzato" per tutti ma uno dei master (quindi solo uno generato dal master).

• Modificare lo script di pre-build per ogni versione per copiare il contenuto del file delle impostazioni appropriato nel file build-master.

• Modificare lo script post-generazione per copiare nuovamente il contenuto del file master secondario nel 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 controlla nel post-build. Tuttavia, ciò potrebbe causare problemi in un ambiente di integrazione continua poiché un file bloccato richiederebbe il fallimento della build.

Non l'ho mai fatto; anche se ci sono momenti in cui vorrei che ci fosse un modo più originale di fare qualcosa del genere in VS.

Answer 3

Un pensiero è che passare da una serie di valori statici suona come un modo piuttosto complesso di fare le cose. Suggerirei di cercare il pattern Singleton. Questo modello fornisce una singola istanza di classe condivisa tra tutti i riferimenti alla classe, ma quando viene caricata per la prima volta è possibile eseguire i normali bit di inizializzazione per verificare il proprio ambiente e impostare i valori di conseguenza.

Allo stesso modo, piuttosto che utilizzare gli switch per agire su classi diverse, non dovresti considerare la progettazione di un'interfaccia e l'implementazione di tale interfaccia da parte di ogni classe?

Answer 4

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

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

Visual Studio 2010 avrà questa caratteristica anche. Si chiama Config Transformation

Answer 5

C'è un po 'di overhead coinvolto nel fare un controllo per determinare quale ambiente si sta eseguendo. Se si sta parlando di un ambiente web, questo potrebbe significare un notevole calo di prestazioni. Raccomanderei di creare tre file di configurazione separati e di configurare un sistema continuo di integrazione e distribuzione che gestisca la denominazione e il roll out del file di impostazioni corretto in base all'ambiente. Nel tuo caso avresti tre file, Production.config, Development.config e Test.config. Il server di integrazione creerebbe quindi una copia di questo file per web.config o app.config in base all'ambiente.

Per quanto riguarda la manutenzione aggiuntiva necessaria per il mantenimento di tre file separati ogni volta che viene apportata una modifica alla configurazione, manteniamo i file formattati automaticamente e utilizziamo qualcosa come WinMerge per vedere facilmente le differenze e mantenerle nella giusta sincronizzazione. Questi tipi di file in genere non richiedono molte modifiche e quando lo fanno sono in genere aggiunte minori.

Answer 6

Attualmente faccio qualcosa di simile alla soluzione menzionata da pdavis. Ma per semplificare più file di configurazione, utilizzo un modello T4 per creare i file di configurazione specifici per l'ambiente. In questo modo c'è un file web.tt che gestisce la generazione del file web.config predefinito. Ogni ambiente ha il proprio file di modello (qa.tt, production.tt, etc) che eredita da web.tt e contiene eventuali sostituzioni specifiche dell'ambiente. Eventuali modifiche alla configurazione Web: nuove impostazioni dell'app, impostazioni di configurazione, ecc. Vengono automaticamente propagate a tutti i file di configurazione specifici della regione mediante la rigenerazione dei modelli e non è necessario preoccuparsi di mantenere i file sincronizzati utilizzando uno strumento diff.