Come gestire i file di configurazione di Windows .NET

3

Usiamo il normale file app.config per la configurazione dell'applicazione. Sebbene funzioni per ora ha alcuni inconvenienti piuttosto significativi:

  • L'aggiornamento di un'applicazione con app.config modificato è difficile. O sovrascrive il file di configurazione esistente o il% aggiornatoapp.config non è installato affatto.
  • Un errore in app.config spesso rende non valida l'intera configurazione.
  • I file sono di sola lettura e non possono essere modificati dall'applicazione stessa.

Per superare questi problemi, sto considerando alcune opzioni alternative.

Trasformazione documento XML personalizzato

Un'alternativa sarebbe tornare a un file XML personalizzato per evitare questi inconvenienti. Penso a una soluzione che utilizza trasformazione dei documenti XML .

Il programma di installazione installerà il file di configurazione predefinito default.xml ed è di sola lettura. Non deve mai essere modificato, perché viene sovrascritto durante un aggiornamento. Contiene tutte le impostazioni predefinite e dovrebbe essere sufficiente per avviare l'applicazione.

Le modifiche possono essere eseguite nei file custom-xxx.xml elaborati in ordine alfabetico. Le modifiche vengono eseguite utilizzando la sintassi XDT come descritto qui .

Il file risultante verrà scritto in configuration.xml che è stato effettivamente utilizzato. Il file configuration.xml non dovrebbe mai essere modificato direttamente, perché verrà sovrascritto quando l'applicazione viene riavviata.

Penso che questo approccio abbia alcuni vantaggi:

  • La configurazione predefinita può essere aggiornata durante l'aggiornamento di un'applicazione.
  • Le modifiche alla configurazione locale possono essere applicate e verranno mantenute durante gli aggiornamenti.
  • Se non è possibile applicare la trasformazione (errore di sintassi), il file viene saltato, ma è sempre possibile leggere la configurazione predefinita.

Ci sono anche alcuni svantaggi:

  • XDT non è banale per la maggior parte degli utenti e soggetto a errori
  • La modifica della configurazione dall'interno dell'applicazione è difficile, perché è necessario scrivere un file XDT.
  • Non tutte le impostazioni possono essere eseguite al di fuori di app.config , perché il framework .NET cerca determinate impostazioni in questo file.

Solo personal.xml

L'applicazione ha le impostazioni predefinite specificate nel codice. Queste impostazioni possono essere sostituite dall'applicazione utilizzando un file custom.xml . Questo ha alcuni vantaggi:

  • I valori predefiniti sono specificati nel codice, quindi verranno aggiornati automaticamente quando l'applicazione viene aggiornata.
  • Le modifiche alla configurazione locale possono essere applicate e verranno mantenute durante gli aggiornamenti.
  • Se custom.xml contiene errori, questo file viene saltato e le impostazioni predefinite possono ancora essere utilizzate.
  • Relativamente facile creare una GUI per modificare le impostazioni e scrivere solo le impostazioni non predefinite.

Ci sono anche alcuni svantaggi:

  • Non c'è default.xml , quindi non tutte le opzioni sono chiaramente visibili nel file XML.
  • Quando la configurazione predefinita contiene un elenco, non è possibile rimuovere elementi dall'elenco in custom.xml . Le configurazioni dovrebbero essere modellate in modo tale che queste circostanze possano essere gestite.

Wrap-up

Esistono diversi scenari per gestire i file di configurazione. Vorrei sapere come gestire le configurazioni in situazioni in cui i file di configurazione devono essere personalizzati e si desidera mantenere gli scenari di aggiornamento automatici.

    
posta Ramon de Klein 21.11.2014 - 10:49
fonte

3 risposte

1

Penso che parte dei problemi che stai affrontando sia nella premessa:

Upgrading an application with a modified app.config is hard. Either it overwrites the existing configuration file or the upgraded app.config isn't installed at all.

Non farlo, in pratica. La configurazione è un artefatto software, e dovrebbe essere versionata e passare attraverso lo stesso ciclo di vita di qualsiasi altro artefatto, soggetto a controllo delle modifiche e qualsiasi altra salvaguardia che il tuo team implementa per gli artefatti software.

Suppongo che realisticamente, in un ambiente di produzione è probabile che si abbiano degli hack creati con la configurazione dell'applicazione per risolvere i problemi in caso di emergenza. Idealmente, l'immediata conseguenza di doverlo fare sarebbe un cambiamento correttamente gestito che verrebbe distribuito formalmente alla produzione non appena umanamente possibile. Pertanto un aggiornamento programmato avrebbe già questo cambiamento e la regressione non dovrebbe essere un problema.

Criticare la premessa probabilmente non fornisce una risposta adeguata, quindi potresti espandere la tua domanda per fornire un esempio del tipo di impostazioni che ritieni problematiche?

    
risposta data 21.11.2014 - 19:01
fonte
0

Nelle nostre applicazioni, usiamo solo app.config per puntare ai server correlati (web, db, licenza). Qualsiasi altro tipo di dati di configurazione è

  • memorizzato come file di configurazione utente locale (presupposto che i dati di configurazione siano importanti solo per l'aspetto dell'applicazione della macchina locale, quindi non disperdibili)

  • o memorizzati nel database (se si tratta di dati di configurazione più importanti, che devono essere sottoposti a backup)

Questo significa

  • non abbiamo mai avuto bisogno di aggiornare / modificare app.config dal programma di installazione dopo la prima installazione, poiché non modifica mai la sua struttura

  • forniamo una GUI all'interno dell'applicazione per tutti i tipi di configurazioni, database o file locali, qualsiasi cosa sia necessaria

  • ogni volta che i dati di configurazione vengono estesi, la GUI fornisce valori predefiniti significativi e vi è sempre un pulsante "Ripristina predefiniti" per i dati correlati, o un pulsante "copia da altro progetto", se è progetto- dati di configurazione correlati.

Usando questa strategia, in realtà non ha importanza per l'utente o per i clienti, come i dati sono memorizzati internamente . Cerca di evitare la necessità per gli utenti di modificare manualmente qualsiasi XML, quindi l'intera domanda diventa inutile, basta scegliere il formato che puoi elaborare più facilmente nel tuo programma.

    
risposta data 22.11.2014 - 10:56
fonte
0

Hai pensato di suddividere il tuo file di configurazione in diversi file? Guarda in configsource, che ti permette di fare riferimento a un file separato per una sezione nella tua configurazione.

<pages configSource="pages.config"/>

link

Puoi usarlo per inserire valori che cambiano spesso in un file più piccolo, semplificando la manutenzione.

    
risposta data 22.11.2014 - 16:15
fonte

Leggi altre domande sui tag