Come gestisci i file app.config .NET per applicazioni di grandi dimensioni?

Question

Supponiamo che un'applicazione composita di grandi dimensioni sia costruita su diversi componenti di base impacchettati nei propri assembly:(lettura del database, gestori di protocollo, ecc.).Per alcune distribuzioni, ciò può includere oltre 20 assembly.Ciascuno di questi assembly dispone di impostazioni o informazioni di configurazione.Il nostro team tende ad apprezzare l'editor delle impostazioni VS (e il codice facile da usare che genera!), e l'applicazione vs.la distinzione degli utenti soddisfa la maggior parte delle nostre esigenze.

MA....

È molto noioso copiare e incollare le numerose sezioni di configurazione nel file .xml della nostra applicazione.Inoltre, per i componenti condivisi che tendono ad avere configurazioni simili tra le applicazioni, ciò significa che dobbiamo mantenere impostazioni duplicate in più file .config.

EntLib di Microsoft risolve questo problema con uno strumento esterno per generare il file .config mostruoso, ma anche questo sembra goffo.

Quali tecniche usi per gestire file .NET .config di grandi dimensioni con sezioni di più assembly condivisi?Una sorta di meccanismo di inclusione?Lettori di configurazione personalizzata?

SEGUITO:

Will's risposta era esattamente ciò a cui volevo arrivare e sembra elegante per le sezioni piatte di coppie chiave/valore.C'è un modo per combinare questo approccio con sezioni di configurazione personalizzata ?

Grazie anche per i suggerimenti sulla gestione di diversi .config per diversi target di build.Anche questo è abbastanza utile.

Dave

Answer 1

Utilizzi un file di configurazione principale che punta ad altri file di configurazione. Ecco un esempio di come eseguire questa operazione.

---

Nel caso in cui il collegamento marcisca, ciò che fai è specificare il file configSource per una particolare sezione di configurazione.Ciò consente di definire quella particolare sezione all'interno di un file separato.

<pages configSource="pages.config"/>

il che implica che esiste un file chiamato "pages.config" all'interno della stessa directory che contiene l'intero <pages /> albero dei nodi.

Answer 2

Il mio metodo preferito è utilizzare MSBuild, se fai clic con il pulsante destro del mouse su un progetto e fai clic su "scarica" ​​verrà visualizzata una nuova opzione di menu che dice "modifica".Selezionalo e si aprirà il file di progetto in modo da poterlo modificare, scorrere verso il basso fino a trovare una sezione commentata chiamata "AfterBuild".

Puoi quindi aggiungere qualcosa come:

<Target Name="AfterBuild">
    <Delete Files="$(TargetDir)$(TargetFileName).config" />
    <Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>

Ciò sostituirà la configurazione dell'applicazione con una denominata [Release|Debug]app.exe.config.Quindi puoi mantenere configurazioni separate a seconda di come viene costruito il progetto.

Ma un'opzione rapida e sporca (se non vuoi giocare con msbuild) è semplicemente mantenere file di configurazione separati e quindi definire quale vuoi includere, in questo modo:

<appSettings configSource="Config\appSettingsDebug.config"/>
<roleManager configSource="Config\roleManagerDebug.config"/>

E se stai realizzando un'applicazione asp.net, Microsoft fornisce una fantastica utility chiamata "Progetti di distribuzione Web" che ti consentirà di gestire tutto questo facilmente, clicca qui

Answer 3

Un ottimo modo per gestire grandi set di configurazioni è creare sezioni di configurazione personalizzate.Phil Haack ne parla molto bene in questo articolo Sezioni di configurazione personalizzata in 3 semplici passaggi

Answer 4

Imposta le configurazioni di build per ciascuno dei tuoi ambienti di distribuzione/test e utilizza file di configurazione separati in base a ciascuna configurazione di build.

ScottGu ha un bel post su questo e funziona benissimo.L'unico problema che abbiamo è che dobbiamo assicurarci che i file di configurazione (web.config) siano estratti per la modifica da TFS prima di ogni build in modo che possano essere copiati.

Answer 5

Abbiamo creato una classe AssemblySettingsConfig che agisce come ConfigurationManager, ma carica un file .config per ogni singolo assembly.Pertanto l'applicazione ha un file .config e tutte le DLL a cui fa riferimento hanno i propri file .config.Ha funzionato bene finora.