Only the mono compiler caught that warning. The nant builds for .NET 1.0 and 2.0 didn't report any warnings.
There's no particular reason why I marked it as virtual other than the other implemented members of the class are virtual. I understand your point about the virtual Format method calling the abstract Format method...I'll remove the virtual marker and explain that the method just creates a local StringWriter to pass to the other Format method. ----- Original Message ---- From: Curt Arnold <[EMAIL PROTECTED]> To: Log4NET Dev <log4net-dev@logging.apache.org> Sent: Tuesday, January 1, 2008 5:50:03 PM Subject: Re: [EMAIL PROTECTED]: Project logging-log4net (in module logging-log4net) failed On Jan 1, 2008, at 2:12 AM, <[EMAIL PROTECTED]> wrote: > To whom it may engage... > > This is an automated request, but not an unsolicited one. For > more information please visit http://gump.apache.org/nagged.html, > and/or contact the folk at [EMAIL PROTECTED] > > Project logging-log4net has an issue affecting its community > integration. > This issue affects 1 projects. > The current state of this project is 'Failed', with reason 'Build > Failed'. > For reference only, the following projects are affected by this: > - logging-log4net : Logging framework for .NET. > > > Full details are available at: > http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/index.html > > That said, some information snippets are provided here. > > The following annotations (debug/informational/warning/error > messages) were provided: > -INFO- Failed with reason build failed > > > > The following work was performed: > http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/gump_work/build_logging-log4net_logging-log4net.html > Work Name: build_logging-log4net_logging-log4net (Type: Build) > Work ended in a state of : Failed > Elapsed: 22 secs > Command Line: NAnt.exe -D:java.awt.headless=true -D:gump.merge=/srv/ > gump/public/gump/work/merge.xml -D:build.sysclasspath=only - > buildfile:log4net.build > [Working Directory: /srv/gump/public/workspace/logging-log4net] > DEVPATH: > --------------------------------------------- > > ... > compile-mono-1.0: > > [csc] Compiling 211 files to '/srv/gump/public/workspace/ > logging-log4net/bin/mono/1.0/debug/log4net.dll'. > [csc] /srv/gump/public/workspace/logging-log4net/src/Layout/ > PatternLayout.cs(726,22): error CS0419: Ambiguous reference in cref > attribute `PatternLayout.Format'. Assuming > `log4net.Layout.PatternLayout.Format(System.IO.TextWriter, > log4net.Core.LoggingEvent)' but other overloads including > `log4net.Layout.LayoutSkeleton.Format(log4net.Core.LoggingEvent)' > have also matched > [csc] Compilation failed: 1 error(s), 0 warnings > > BUILD FAILED - 0 non-fatal error(s), 1 warning(s) > > /srv/gump/public/workspace/logging-log4net/log4net.build(596,14): > External Program Failed: /opt/mono/lib/pkgconfig/../../lib/mono/1.0/ > mcs.exe (return code was 1) > > Total time: 6 seconds. > The problem appears to be rev 607786 which added a second Format method to LayoutSkeleton.cs. I added the arguments in the cref in PatternLayout to get things building again in rev 607933. Does it make sense to make the new Format method virtual since it is an delegate to an abstract method? It would seem to add confusion and potential conflict over which to override. I'd make it final, but I haven't been following it.
