Okay... I think I figured it out. One of the classes calling
log_ = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMeth od().DeclaringType); was in a shared, utility dll. Being a shared dll, it didn't have an XmlConfigurator assembly attribute. As it happened, that was also the first reference to log4net.LogManager, so that's when the instance got initialized. Since that assembly gave log4net no direction, it returned a default logger. It appears that subsequent calls to log4net.LogManager.GetLogger from other assemblies *with* the XmlConfigurator attribute were too late to the game and the config wasn't loaded - highlighting the importance of precedence in getting loggers. Thanks Mark This e-mail message, and any attachments, is intended only for the use of the individual or entity identified in the alias address of this message and may contain information that is confidential, privileged and subject to legal restrictions and penalties regarding its unauthorized disclosure and use. Any unauthorized review, copying, disclosure, use or distribution is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message, and any attachments, from your system. Thank you. ________________________________ From: Radovan Raszka [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 11, 2007 6:38 AM To: Log4NET User Subject: RE: Trouble using XmlConfigurator assembly attribute Windows services behaves a little differently compare to "normal" applications - current directory for service is %systemroot%/system32, not directory where executable resides - that's why services doesn't see log4net config file. I use in such situation this solution: configure log4net using Xmlconfigurator.Configure(path_to_config), where path_to_config is string myPath = System.Reflection.Assembly.GetExecutingAssembly().Location; int i = myPath.LastIndexOf('\\'); string path_to_config = myPath.Remove(i + 1) + "log4net.config"; Radovan ________________________________ From: Mark Modrall [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 11, 2007 1:21 AM To: Log4NET User Subject: RE: Trouble using XmlConfigurator assembly attribute Sorry it took me a while to respond... Evening commute and the like... I tried making the path explicit in the AssemblyInfo.cs setting, but it didn't help. The app is a windows service, the application type is Console, and all the assemblies are signed, in case that makes a difference. Thanks Mark This e-mail message, and any attachments, is intended only for the use of the individual or entity identified in the alias address of this message and may contain information that is confidential, privileged and subject to legal restrictions and penalties regarding its unauthorized disclosure and use. Any unauthorized review, copying, disclosure, use or distribution is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message, and any attachments, from your system. Thank you. ________________________________ From: Dave McEwan [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 5:05 PM To: Log4NET User Subject: RE: Trouble using XmlConfigurator assembly attribute Just curious...if you put the full path in the assemblyInfo file like so what happens: [assembly: log4net.Config.XmlConfigurator(ConfigFile = "C:\MyApp\bin\App.log4net", Watch = true)] ________________________________ From: Mark Modrall [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 5:01 PM To: Log4NET User Subject: RE: Trouble using XmlConfigurator assembly attribute Yep... I'm leaving the assembly attributes in and just adding the line to Main(). If I have it done directly in Main() it gets the right config; if I leave it to the assembly attributes, it doesn't. Assemblies and configs all go to the same dir. That's why I'm scratching my head... Thanks Mark This e-mail message, and any attachments, is intended only for the use of the individual or entity identified in the alias address of this message and may contain information that is confidential, privileged and subject to legal restrictions and penalties regarding its unauthorized disclosure and use. Any unauthorized review, copying, disclosure, use or distribution is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message, and any attachments, from your system. Thank you. ________________________________ From: Dave McEwan [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 4:58 PM To: Log4NET User Subject: RE: Trouble using XmlConfigurator assembly attribute Are you sure that your config file is in the "same" directory as the executable? ________________________________ size=2 width="100%" align=center tabIndex=-1> From: Mark Modrall [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 4:56 PM To: [email protected] Subject: Trouble using XmlConfigurator assembly attribute Hi... I've got some programs/assemblies that I'm building and for some reason, the XmlConfigurator assembly attribute isn't working. A couple of the assemblies have [assembly: log4net.Config.XmlConfigurator(ConfigFile = "App.log4net", Watch = true)] In their AssemblyInfo.cs files, but when I run the program Log4Net.LogManager.GetLogger("foo"); Doesn't return the logger defined in the file. If I put log4net.Config.XmlConfigurator.Configure(new System.IO.FileInfo("App.log4net")); into the app Main(), though, it does find the config, load it, and return the right logger instance. Is there some trick to using the assembly attribute? Thanks Mark This e-mail message, and any attachments, is intended only for the use of the individual or entity identified in the alias address of this message and may contain information that is confidential, privileged and subject to legal restrictions and penalties regarding its unauthorized disclosure and use. Any unauthorized review, copying, disclosure, use or distribution is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message, and any attachments, from your system. Thank you.
