Nicko, This sounds perfect! I agree the IFormatProvider overload makes sense.
So the new methods would be: void DebugFormat(string format, params object[] args); void DebugFormat(IFormatProvider provider, string format, params object[] args); void InfoFormat(string format, params object[] args); void InfoFormat(IFormatProvider provider, string format, params object[] args); void WarnFormat(string format, params object[] args); void WarnFormat(IFormatProvider provider, string format, params object[] args); void ErrorFormat(string format, params object[] args); void ErrorFormat(IFormatProvider provider, string format, params object[] args); void FatalFormat(string format, params object[] args); void FatalFormat(IFormatProvider provider, string format, params object[] args); Will you make the change, or should I and send you diffs? -Doug -----Original Message----- From: Nicko Cadell [mailto:[EMAIL PROTECTED] Sent: Saturday, September 18, 2004 8:09 AM To: Log4NET Dev Subject: RE: New code to allow formatting during logging Doug, I agree that ignoring the exception argument for the xxxFormat methods makes the most sense. It gives users the full power of the string.Format but does not complicate things by forcing them to understand the special processing of the exception. If they want to specify the exception they still can but have to use the older Debug() methods. Therefore we would have to add the following: public void DebugFormat(string format, params object[] args) { Debug(string.Format(format, args)); } public void DebugFormat(IFormatProvider provider, string format, params object[] args) { Debug(string.Format(provider, format, args)); } I still think that it is worth passing the IFormatProvider as that is how the String.Format supports different locales. Will this fulfil your requirements? Nicko
