I am using log4net in my .NET 3.5 console application and would like the log messages I generate to be seen in both the console standard out and the RollingFileAppender. The
I'm having the same problem as OP. In log4net.config I have set debug = false. I also have a single FileAppender set with a PatternLayout defined. When I usse log.Warn("test") I get the expected formatted results written to the expected txt file. However, I also get a more verbose string written to the console (stdout).
EDIT: The fix for me was to eliminate this line in my code BasicConfigurator.Configure(); Note that nothing explicitly telling log4net to write to both console and declared FileAppender was stated in my config. In fact, log4net debug=false was declared and the problem continued to persist. The example code on the log4net homepage carelessly invokes BasicConfigurator.Configure(); Although I do use log4net the library suffers from the same problems of many ambitious open source projects. Lengthy XML driven configurations exist to give developers thousands of options for a task that should really have a more streamlined interface available. Programmers don't tend to value each others time. We apply the "don't make me think" rule in our user interfaces but not in our machine interfaces. It's as if we scorn a core principle that is universal to good design. The complexities should be available to the developer, but a few hours shouldn't be lost to accomplish core functionality. Considering this I would say log4net is poorly designed. As with most software there's a lot of complexity for complexity sake. If the developers guiding the project were more talented the most common use case of the library (referencing then using it to log to a text file in the app folder) could be implemented with 5-10 minutes of expose without any previous knowledge. That's not the case because the interface design and the methodology for configuration. It spotlights the reason I hate the way most software engineers think. They are incapable of seeing the exponential value of simplicity for the most common use cases and instead assume the more puzzling they make the interface the more value it will add to other developers. They are driven by ego and ignorance. No wonder most are social outcast.