All'avvio, chiamare:
XmlConfigurator.Configure();
Nel web.config, specificare log4net.Config in appSettings:
<add key="log4net.Config" value="Log.config" />
Questa impostazione speciale consente di modificare la configurazione del registro senza dover ricompilare . Particolarmente utile per lo spostamento tra più ambienti.
Esempio
consideri la seguente struttura di file di progetto:
\config\log4net\debug.config
\config\log4net\staging.config
\config\log4net\release.config
\config\appSettings\debug.config
\config\appSettings\staging.config
\config\appSettings\release.config
notifica e registrazione configurazioni sono distinti per ciascun ambiente. I riferimenti alle configurazioni di registrazione vengono mantenuti nelle impostazioni dell'applicazione.
\ config \ appsettings \ Debug.config:
<appSettings>
<add key="log4net.Config" value="config\log4net\debug.config" />
...
</appSettings>
\ config \ appsettings \ staging.config:
<appSettings>
<add key="log4net.Config" value="config\log4net\staging.config" />
...
</appSettings>
\ config \ appsettings \ Release.config :
<appSettings>
<add key="log4net.Config" value="config\log4net\release.config" />
...
</appSettings>
La modifica degli ambienti è una semplice questione di aggiornamento del file appSettings in Web.config.
<appSettings file="config\appSettings\staging.config">
...
</appSettings>
Questo è un buon punto, ma io sinceramente non piace questa cosa di configurazione "magica". Quello che ho fatto ora è dichiarare tre chiavi con nomi di file nell'appSettings del Web.config per Debug, Stage, Release e utilizzare le direttive del preprocessore in ApplicationStart per scegliere automaticamente quella giusta in base alla configurazione in cui sono stati distribuiti gli assembly. Qual è la tua opinione? C'è qualcosa di sbagliato in questa soluzione? –
@ Martin: ho aggiunto un esempio per illustrare. L'unico lato negativo della soluzione è l'inflessibilità delle versioni di build rispetto alle alterazioni di web.config. – Anton
thx, per il tuo consiglio! –