As in Log4Net.LoggerManager.Shutdown()
Even though other libraries are not kin on it, any framework that internally supports buffering should allow for explicit flushing of contents by the application.
Tnank you
Note that NLog has a Flush method (actually 3 overloads). It does not sound exactly the same as Log4Net's Shutdown. The Help for NLog's LogManager.Flush says that it flushes any pending log messages, particularly mentioning asynchronous targets. The Help for Log4Net's LogManager.Shutdown method says that it closes and removes all appenders. An apparent side effect of this is that pending messages will be flushed (assuming the appenders flush when closed). So, in the end, both NLog.LogManager.Flush and Log4Net.LogManager.Shutdown will cause messages to be flushed. The difference is that NLog is apparently still usable after Flush while Log4Net is not usable after Shutdown. It seems like it would be ok to represent the requested behavior as a "shutdown" behavior that an app developer could call when his app is being shutdown. It seems reasonable to call NLog.LogManager.Flush or Log4Net.LogManager.Shutdown in either case. The overall implication is that it is not easy to expose a method that "only" flushes since Log4Net does not support that nor is it that easy to expose a shutdown, since calling Flush on NLog does not imply a "shutdown". I believe that it is possible to set NLog.LogManager.Configuration to null, which might be about the equivalent of Log4Net.LogManager.Shutdown. Maybe it would be ok to add Flush AND Shutdown. In case of NLog, Flush flushes and that is all. In case of Log4Net Flush does nothing - maybe not so good. In case of NLog, Shutdown sets LogManager.Configuration = null. In case of Log4Net, Shutdown calls LogManager.Shutdown. Shutdown behavior is probably as similar as possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more note, NLog hooks up to AppDomain.CurrentDomain.ProcessExit and AppDomain.CurrentDomain.DomainUnload events and performs shutdown logic there. So, NLog will automatically shut itself down (essentially by setting LogManager.Configuration = null) when the app exits or when the AppDomain is unloaded. I don't know if Log4Net does something similar or if it must/should be explicitly shut down.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more comment! At this link you can find some code that apparently will flush all buffering appenders in Log4Net. With this, it should be possible to implement a Common.Logging.LogManager.Flush that will actually flush either NLog or Log4Net and leave both in working order. Similarly, if an explicit Shutdown is desired, setting NLog.LogManager.Configuration = null and/or calling Log4Net.LogManager.Shutdown should give more or less equivalent behavior.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that NLog has a Flush method (actually 3 overloads). It does not sound exactly the same as Log4Net's Shutdown. The Help for NLog's LogManager.Flush says that it flushes any pending log messages, particularly mentioning asynchronous targets. The Help for Log4Net's LogManager.Shutdown method says that it closes and removes all appenders. An apparent side effect of this is that pending messages will be flushed (assuming the appenders flush when closed). So, in the end, both NLog.LogManager.Flush and Log4Net.LogManager.Shutdown will cause messages to be flushed. The difference is that NLog is apparently still usable after Flush while Log4Net is not usable after Shutdown. It seems like it would be ok to represent the requested behavior as a "shutdown" behavior that an app developer could call when his app is being shutdown. It seems reasonable to call NLog.LogManager.Flush or Log4Net.LogManager.Shutdown in either case. The overall implication is that it is not easy to expose a method that "only" flushes since Log4Net does not support that nor is it that easy to expose a shutdown, since calling Flush on NLog does not imply a "shutdown". I believe that it is possible to set NLog.LogManager.Configuration to null, which might be about the equivalent of Log4Net.LogManager.Shutdown. Maybe it would be ok to add Flush AND Shutdown. In case of NLog, Flush flushes and that is all. In case of Log4Net Flush does nothing - maybe not so good. In case of NLog, Shutdown sets LogManager.Configuration = null. In case of Log4Net, Shutdown calls LogManager.Shutdown. Shutdown behavior is probably as similar as possible.
One more note, NLog hooks up to AppDomain.CurrentDomain.ProcessExit and AppDomain.CurrentDomain.DomainUnload events and performs shutdown logic there. So, NLog will automatically shut itself down (essentially by setting LogManager.Configuration = null) when the app exits or when the AppDomain is unloaded. I don't know if Log4Net does something similar or if it must/should be explicitly shut down.
One more comment! At this link you can find some code that apparently will flush all buffering appenders in Log4Net. With this, it should be possible to implement a Common.Logging.LogManager.Flush that will actually flush either NLog or Log4Net and leave both in working order. Similarly, if an explicit Shutdown is desired, setting NLog.LogManager.Configuration = null and/or calling Log4Net.LogManager.Shutdown should give more or less equivalent behavior.
Forgot the link ...
http://stackoverflow.com/questions/2045935/is-there-anyway-to-programmably-flush-the-buffer-in-log4net