2009-05-04 11 views
7

Ho una soluzione che include sia un'applicazione Web sia un'applicazione di servizio Windows NT. Questi sono ovviamente due progetti diversi ma all'interno della stessa soluzione. Tuttavia condividono molto la stessa configurazione.File di configurazione condivisi in .NET

Attualmente ho gli stessi valori sia nel file web.config che nel file app.config. Questo sta cominciando a diventare disordinato e mi piacerebbe avere un file di configurazione condiviso per entrambe le applicazioni all'interno della soluzione.

  • Esiste un problema per l'applicazione web se la configurazione non è al livello principale del Web applicazione? Ci sono dei limiti qui?
  • Will perdo caching e riciclo automatico dell'applicazione web se io non uso web.config
  • E 'generalmente una cattiva idea di condivisa la configurazione della stessa?

risposta

9

Bene, è possibile "esternalizzare" alcune parti della configurazione in file .config separati e usarli da entrambi i punti.

E.g. si poteva esternare le impostazioni della stringa di connessione in questo modo:

<connectionStrings configSource="connectionStrings.config" /> 

e quindi avere il file "connectionString.config" come questo:

<?xml version="1.0" encoding="utf-8"?> 
<connectionStrings> 
    <add name="ConfigurationDatabase" 
     connectionString="server=.;Integrated Security=true;database=test"/> 
    <add name="TestDatabase" 
     connectionString="server=TEST;Integrated Security=true;database=test"/> 
</connectionStrings> 

In sostanza, qualsiasi ConfigurationSection ha un ambiente così "configSource", che ti permette di specificare un file esterno da usare.

In questo modo, è possibile condividere parti comuni dei due file di configurazione.

Marc

+0

L'attributo configSource non consente di inserire ".." o "~ /" al suo interno e indica "È necessario fare riferimento a un file nella stessa directory o in una sottodirectory come file di configurazione." Detto questo, in che modo due progetti possono condividere un file esterno se nessuno dei due può raggiungere un livello di directory superiore a se stesso? –

+0

@James in Indy: puoi utilizzare la funzionalità a livello di file system NTFS, come i link hard e soft, che possono far apparire un file in una directory, anche se non è proprio lì ... (è solo un link/puntatore al file attuale). Google per "NTFS hard link" o "NTFS junction points" –

2

sarà ancora bisogno di un web .config in quanto vi sono elementi di configurazione che sono specifici web che non sarà nel app.config del vostro servizio. Come Marc says, l'utilizzo dell'attributo ConfigSource consente di condividere elementi comuni.

Si noti che l'elemento appSettings ha una leggera differenza: l'attributo File.

Specifica un percorso relativo a un file esterno che contiene le impostazioni di configurazione dell'applicazione personalizzate. Il file specificato contiene lo stesso tipo di impostazioni che sono specificate nell'appSettings, aggiungi, cancella e rimuovi attributi e usa lo stesso formato di coppia chiave/valore di quegli elementi.

Questo comporta in modo diverso per l'attributo configSource, perché non c'è bisogno di sostituire l'intera sezione con il file esterno, può solo contenere elementi che si desidera avere in aggiunta, o per ignorare i valori:

È possibile utilizzare l'attributo di file per specificare un file di configurazione che fornisce ulteriori impostazioni o ignora le impostazioni specificati nell'elemento appSettings.

Se si utilizza ConfigSource di condividere altri elementi, allora si avrà ancora riavvii automatici dell'applicazione quando i valori vengono modificati - la nota sui restartOnExternalChanges attributo deve essere ignorato per le applicazioni ASP.NET, ma utilizzando il File attributo significherà che le modifiche non causeranno un riavvio.

Il contenuto dei file esterni deve essere ancora memorizzato nella cache, quindi le prestazioni non dovrebbero essere influenzate.

Problemi correlati