Change in 3.4.0: missing event source error is now returned from "XmlConfigurator.ConfigureAndWatch" #332

Activity

1. FreeAndNil commented on Sep 28, 2026

   

   FreeAndNil

   on Sep 28, 2026

   Last edited by FreeAndNil

   Contributor

   More actions

   Hi @WolfgangHG,

   thank you for the report and the sample project.

   This is an intended change, but your case was not thought about.

   In 3.4.0 OnlyOnceErrorHandler, the default error handler of every appender, writes the first error
   always. Before it did that only with log4net.Internal.Debug on. The reason: an appender could stop
   working and nobody would see it. See the 3.4.0 changelog, "report the first error of an appender
   even when log4net.Internal.Debug is off" (#310).

   ecd1b8b
   Upgrade note: previously invisible appender errors are now visible, so a misconfigured appender emits one log4net:ERROR line on stderr.

   XmlConfigurator.ConfigureAndWatch collects all internal messages and returns them. So an appender
   error is now in that list too, not only errors from the config file. Your check "list is not empty"
   is therefore stricter than before.

   LogLog.EmitInternalMessages = false does not help, it only stops the console output.
   log4net.Internal.Quiet hides every internal error, which you probably do not want.

   Filtering works. Appender errors come from OnlyOnceErrorHandler, config errors from another type:

   ICollection messages = XmlConfigurator.ConfigureAndWatch(new FileInfo("..\\..\\..\\Logger4netXML.config"));
   
   List<log4net.Util.LogLog> configErrors = messages
     .Cast<log4net.Util.LogLog>()
     .Where(m => m.Source != typeof(log4net.Util.OnlyOnceErrorHandler))
     .ToList();
   
   if (configErrors.Count > 0)
   {
     foreach (log4net.Util.LogLog x in configErrors)
     {
       Console.WriteLine(x);
     }
   }

   The appender in your stack trace is not ours, but our own EventLogAppender sends the same message.

   An appender that cannot start is a configuration problem, so its error belongs in that list.
   The filter above is the way to separate it from errors in the config file.

   Does that solve your problem?
2. WolfgangHG commented on Sep 29, 2026

   

   WolfgangHG

   on Sep 29, 2026

   Author

   More actions

   @FreeAndNil Thanks for the clarification. I will implement the suggested workaround.
   It is obvious that forwarding a logger initialization error is the correct approach. Previously, the logger would have been disabled silently, which makes it hard to diagnose the missing log.

   I will close this issue if one bonus question is answered 😄:
   Thinking about the EventLogAppender, which is not available in .NET6+ applications: the workaround is to use another nuget package, but the source repository of Log4Net.Appenders.NetCore does not even exist any more. The default log4net.Appender.EventLogAppender should probably work if the log4net Nuget package contains also an assembly for the target framework net8.0-windows. But there were probably good reasons for not doing this?
   If adding another target framework is possible, I could create a new issue to follow this.
3. FreeAndNil commented on Sep 29, 2026

   

   FreeAndNil

   on Sep 29, 2026

   Contributor

   More actions

   @WolfgangHG we are considering to move the Windows only Appenders into their own package (and support for modern .net).
   See #267 (#267 (reply in thread))
   Please comment on the discussion what you would like to see,
4. WolfgangHG commented on Sep 29, 2026

   

   WolfgangHG

   on Sep 29, 2026

   Author

   More actions

   Thanks, Closing this one.
5. WolfgangHG

   closed this as completedon Sep 29, 2026