Reputation: 2229
My application should support several logging scenarios that might be either given by environmental settings or user defined flags:
Debug - triggered either by a startup parameter, when a debugger is attached or the built configuration is set to debug. Active appenders: DebugAppender (logs to the attached debugger, if available).
Verbose - triggered by a startup parameter. Active appenders: Default, but appenders should have a more expressive output (string pattern) for additional info
Release - triggered by the RELEASE build configuration. Active appenders: RollingFlatFileAppender, EventLogAppender (since it is a Windows servce)
Console - triggered by a startup parameter. Active appenders: ColoredConsoleAppender
It should be possible to mix certain modes, e.g. Release/Console, Release/Console/Verbose, Debug/Console, Debug/Verbose.
Does log4net support such a dynamic configuration? It tried with serving different log4net-config files using pre-build actions, however this only works for RELEASE and DEBUG build configurations, not including the startup parameters. Or are there any other logging framework which might support such scenarios the easy way? (e.g. not altering app.config at runtime which is just a PITA)
Upvotes: 0
Views: 2391
Reputation: 14962
I am going to repeat myself (kind of) by mentioning a previous question of yours. Just as I advised you previously I'd really recommend declaring all the appenders and then filtering them based on properties declared on the global log4net context. Of course since you want to mix and match your appenders you would not have one property to do the routing but rather x properties each corresponding to an appender:
<appender name="ColoredConsoleAppender"
type="log4net.Appender.ColoredConsoleAppender,log4net">
<filter type="log4net.Filter.PropertyFilter">
<key value="ConsoleAppenderActive" />
<stringToMatch value="true" />
<acceptOnMatch value="true" />
</filter>
<filter type="log4net.Filter.DenyAllFilter" />
Then in your startup code you would set up all the properties:
log4net.GlobalContext.Properties["ConsoleAppenderActive"] =
ParametersContainConsoleAppenderActive ? "true" : "false";
There is only the trigger for the debugger; for this I didn't find any event firing when the debugger is attached, so you could poll the System.Diagnostics.Debugger.IsAttached value in order to set the property on the log4net context.
Finally the release build can simply be taken care of by a #IF DEBUG
directive. Apart from the polling, every property can be activated at startup so you should have a very tight surface area for your logging configuration.
Upvotes: 0
Reputation: 4284
You can configure log4net in code easily enough. There's another stackoverflow question here which shows how that's done: Enable file logging for log4net from code instead of from configuration
I'm not sure about how attaching a debugger could trigger activation of the Debug configuration, but you could setup Visual Studio to add a command line parameter at startup via the Debug -> Command Line Options in Project Settings (Visual Studio).
The configuration settings could be switched by "#if DEBUG" preprocessing statements, etc. but I'd just stick to command line parameters to simplify your builds.
By the way, you can use the console appender even when you have something running as a Windows service without problems.
Upvotes: 1