netcommon-developer — Discussion on the development of the netcommon libraries

[Netcommon-developer] A new method to the LogManager

[Mogalayapalli, M. <Mur...@ne...>]

Hi,
Is there any plan to add a method to get the CurrentNamespaceLogger in the LogManager class.

Like
LogManager.GetCurrentNamespaceLogger();

Thanks
-Murali

[Netcommon-developer] Problem logging Exception (Log4Net)

[David B. <dbe...@gm...>]

Hi,

I'm having problem understanding why

logger.Error("Application error.",someException); works

and

logger.Error(l => l("Application error.", someException)); does not.

The exception doesn't show up in the logfile.

Re: [Netcommon-developer] Common.Logging: : Input string was not in a correct format

[Stephen B. <sb...@gm...>]

If that's really where it originates, then it would appear the trouble is
the presence of { } characters in the call to string.Format(...), is that
right?  If that's the case, then the only real way I see to correct this
would be to ensure that { } are properly escaped in the input to
string.Format(...).  I'm not sure there is a 'workaround' in the sense of
something that wouldn't require a change in the underlying Common.Logging
code itself -- any solution would probably mean changing code and releasing
a new version of Common.Logging (if I'm properly understanding your
description of the issue).

I *do* completely agree that arbitrarily-embedded { } chars should be
supported as literals in the message-being-logged (since as you point out
you're not always in complete control of the message content) so I'd think
we'd want to make exactly that kind of a change (e.g., pre-process incoming
messages by passing them through a function that would do a simple
substitution of "This is a message with { and } in it." to something more
like "This is a message with \{ and \} in it."

We'd be happy to review a pull request if you want to fork the repo and
propose a fix; else we can obviously put this (relatively) high in the
backlog for the existing contributors as well.  If you want to take a stab
at proposing a fix, please let us know and we'll avoid pursuing it directly
ourselves pending your pull request.

Thanks for your help in isolating the issue~!

Cheers,

-Steve B.

Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen



On Fri, Dec 14, 2012 at 10:13 AM, Peter Kirk <pk...@al...> wrote:

> Thanks. I have done that.
>
> I have also looked into the common-logging source, and I think I see where
> and why the error occurs.
> It appears it stems from class AbsractLogger, in the method:
>
> private string FormatMessage(string format, params object[] args)
> {
>   cachedMessage = string.Format(formatProvider, format, args);
>   return cachedMessage;
> }
>
> Where obviously any { } is interpreted as format parameters.
>
> Any ideas to a good workaround? I sometimes want to log strings which
> originate elsewhere, and which may contain { }. And I "always" use the
> lambda expression call to common-logging, as I find it extremely useful.
>
> Thanks,
> Peter
>
>
>
> From: Stephen Bohlen [mailto:sb...@gm...]
> Sent: 14. december 2012 15:56
> To: Peter Kirk
> Cc: net...@li...
> Subject: Re: [Netcommon-developer] Common.Logging: : Input string was not
> in a correct format
>
> Hmm...I have to agree that sounds like a Common.Logging issue after all --
> thanks for your help in trying to better isolate the problem.  Can you open
> an issue here
> https://github.com/net-commons/common-logging/issues?state=open and we'll
> try to look into it for you soon --?
>
> Thanks again,
>
> -Steve B.
>
>
> Steve Bohlen
> sb...@gm...
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
>
>
> On Fri, Dec 14, 2012 at 9:47 AM, Peter Kirk <pk...@al...> wrote:
> Hi - thanks for your reply.
>
> If I try the following, then the failure occurs when passing the lambda
> expression to common.logging.
> So log4net itself, and the non-lambda call to common-logging work fine.
> But when trying to pass the lambda, common-logging doesn't like it.
>
> log4net.Config.XmlConfigurator.Configure(new FileInfo("log4net.config"));
> log4net.ILog log4netLog = log4net.LogManager.GetLogger("TestApp");
>
> Common.Logging.ILog commonLog =
> Common.Logging.LogManager.GetCurrentClassLogger();
>
> log4netLog.Debug("log4net {a}");
> commonLog.Debug("common logging {a}");
> commonLog.Debug(m => m("common logging lambda {a}"));
>
>
> /Peter
>
>
> From: Stephen Bohlen [mailto:sb...@gm...]
> Sent: 14. december 2012 14:40
> To: Peter Kirk
> Cc: net...@li...
> Subject: Re: [Netcommon-developer] Common.Logging: : Input string was not
> in a correct format
>
> I am nearly certain that this issue is coming from Log4Net rather than
> Common.Logging.  Assuming this email contains your full stack trace, you
> can see this too by noting the root exception seems to originate from
> log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter
> writer).
>
> IIRC in Log4Net the { } characters are used as replacement tokens in log
> message formatting strings and so are probably either reserved entirely or
> need to be escaped.  Common.Logging isn't doing any 'processing' of the log
> messages, merely passing them off to whatever logging framework you're
> using so I'd start there.  The simplest way to confirm this would probably
> be to try to wire up log4net to a test class of your own and forcibly try
> to process a log message like...
>
> log.Debug(m => m("this is a test with some { and } characters"));
>
> ...and see if log4net can handle that 'natively' using your same log4net
> configuration/logging format settings.
>
> Let us know if this helps~!
>
> -Steve B.
>
>
> Steve Bohlen
> sb...@gm...
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
>
> On Fri, Dec 14, 2012 at 5:13 AM, Peter Kirk <pk...@al...> wrote:
> Hi, I am using common.logging (with log4net 1.2.10). Sometimes, when I try
> to log a string which I received from an external service, the logging
> system throws an exception. I am not sure if the exception originates from
> common.logging or log4net.
>
> For example, I do:
> string s = service.GetName();
> log.Debug(m => m("servicename=" + s));
>
> It appears this exception occurs because the string contains '{' and/or
> '}' characters. Can this be correct? (Maybe the name I get is
> "Service81{loc17}").
>
> <log4net.Error>Exception rendering object type
> [Common.Logging.Factory.AbstractLogger+FormatMessageCallbackFormattedMessage]<stackTrace>System.FormatException:
> Input string was not in a correct format.
>    at System.Text.StringBuilder.AppendFormat(IFormatProvider provider,
> String format, Object[] args)
>    at System.String.Format(IFormatProvider provider, String format,
> Object[] args)
>    at
> Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.FormatMessage(String
> format, Object[] args)
>    at
> Alpha.Portal.ServiceAccess.Search.<>c__DisplayClass6.<AllContent>b__5(FormatMessageHandler
> m)
>    at
> Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.ToString()
>    at log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap
> rendererMap, Object obj, TextWriter writer)
>    at log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj,
> TextWriter writer)</stackTrace></log4net.Error>
>
> Thanks for any comments,
> Peter
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>
>
>

Re: [Netcommon-developer] Common.Logging: : Input string was not in a correct format

[Peter K. <pk...@al...>]

Thanks. I have done that.

I have also looked into the common-logging source, and I think I see where and why the error occurs.
It appears it stems from class AbsractLogger, in the method:

private string FormatMessage(string format, params object[] args)
{
  cachedMessage = string.Format(formatProvider, format, args);
  return cachedMessage;
}

Where obviously any { } is interpreted as format parameters.

Any ideas to a good workaround? I sometimes want to log strings which originate elsewhere, and which may contain { }. And I "always" use the lambda expression call to common-logging, as I find it extremely useful.

Thanks,
Peter



From: Stephen Bohlen [mailto:sb...@gm...] 
Sent: 14. december 2012 15:56
To: Peter Kirk
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging: : Input string was not in a correct format

Hmm...I have to agree that sounds like a Common.Logging issue after all -- thanks for your help in trying to better isolate the problem.  Can you open an issue here https://github.com/net-commons/common-logging/issues?state=open and we'll try to look into it for you soon --?

Thanks again,

-Steve B.


Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen


On Fri, Dec 14, 2012 at 9:47 AM, Peter Kirk <pk...@al...> wrote:
Hi - thanks for your reply.
 
If I try the following, then the failure occurs when passing the lambda expression to common.logging.
So log4net itself, and the non-lambda call to common-logging work fine. But when trying to pass the lambda, common-logging doesn't like it.
 
log4net.Config.XmlConfigurator.Configure(new FileInfo("log4net.config"));
log4net.ILog log4netLog = log4net.LogManager.GetLogger("TestApp");
 
Common.Logging.ILog commonLog = Common.Logging.LogManager.GetCurrentClassLogger();
 
log4netLog.Debug("log4net {a}");
commonLog.Debug("common logging {a}");
commonLog.Debug(m => m("common logging lambda {a}"));
 
 
/Peter
 
 
From: Stephen Bohlen [mailto:sb...@gm...] 
Sent: 14. december 2012 14:40
To: Peter Kirk
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging: : Input string was not in a correct format
 
I am nearly certain that this issue is coming from Log4Net rather than Common.Logging.  Assuming this email contains your full stack trace, you can see this too by noting the root exception seems to originate from log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter writer).

IIRC in Log4Net the { } characters are used as replacement tokens in log message formatting strings and so are probably either reserved entirely or need to be escaped.  Common.Logging isn't doing any 'processing' of the log messages, merely passing them off to whatever logging framework you're using so I'd start there.  The simplest way to confirm this would probably be to try to wire up log4net to a test class of your own and forcibly try to process a log message like...

log.Debug(m => m("this is a test with some { and } characters"));

...and see if log4net can handle that 'natively' using your same log4net configuration/logging format settings.

Let us know if this helps~!

-Steve B.


Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

On Fri, Dec 14, 2012 at 5:13 AM, Peter Kirk <pk...@al...> wrote:
Hi, I am using common.logging (with log4net 1.2.10). Sometimes, when I try to log a string which I received from an external service, the logging system throws an exception. I am not sure if the exception originates from common.logging or log4net. 
 
For example, I do:
string s = service.GetName();
log.Debug(m => m("servicename=" + s));
 
It appears this exception occurs because the string contains '{' and/or '}' characters. Can this be correct? (Maybe the name I get is "Service81{loc17}").
 
<log4net.Error>Exception rendering object type [Common.Logging.Factory.AbstractLogger+FormatMessageCallbackFormattedMessage]<stackTrace>System.FormatException: Input string was not in a correct format.
   at System.Text.StringBuilder.AppendFormat(IFormatProvider provider, String format, Object[] args)
   at System.String.Format(IFormatProvider provider, String format, Object[] args)
   at Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.FormatMessage(String format, Object[] args)
   at Alpha.Portal.ServiceAccess.Search.<>c__DisplayClass6.<AllContent>b__5(FormatMessageHandler m)
   at Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.ToString()
   at log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap rendererMap, Object obj, TextWriter writer)
   at log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter writer)</stackTrace></log4net.Error>
 
Thanks for any comments,
Peter

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer
 

Re: [Netcommon-developer] Common.Logging: : Input string was not in a correct format

[Peter K. <pk...@al...>]

Hi - thanks for your reply.

If I try the following, then the failure occurs when passing the lambda expression to common.logging.
So log4net itself, and the non-lambda call to common-logging work fine. But when trying to pass the lambda, common-logging doesn't like it.

log4net.Config.XmlConfigurator.Configure(new FileInfo("log4net.config"));
log4net.ILog log4netLog = log4net.LogManager.GetLogger("TestApp");

Common.Logging.ILog commonLog = Common.Logging.LogManager.GetCurrentClassLogger();

log4netLog.Debug("log4net {a}");
commonLog.Debug("common logging {a}");
commonLog.Debug(m => m("common logging lambda {a}"));


/Peter


From: Stephen Bohlen [mailto:sb...@gm...]
Sent: 14. december 2012 14:40
To: Peter Kirk
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging: : Input string was not in a correct format

I am nearly certain that this issue is coming from Log4Net rather than Common.Logging.  Assuming this email contains your full stack trace, you can see this too by noting the root exception seems to originate from log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter writer).

IIRC in Log4Net the { } characters are used as replacement tokens in log message formatting strings and so are probably either reserved entirely or need to be escaped.  Common.Logging isn't doing any 'processing' of the log messages, merely passing them off to whatever logging framework you're using so I'd start there.  The simplest way to confirm this would probably be to try to wire up log4net to a test class of your own and forcibly try to process a log message like...

log.Debug(m => m("this is a test with some { and } characters"));

...and see if log4net can handle that 'natively' using your same log4net configuration/logging format settings.

Let us know if this helps~!

-Steve B.

Steve Bohlen
sb...@gm...<mailto:sb...@gm...>
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen


On Fri, Dec 14, 2012 at 5:13 AM, Peter Kirk <pk...@al...<mailto:pk...@al...>> wrote:
Hi, I am using common.logging (with log4net 1.2.10). Sometimes, when I try to log a string which I received from an external service, the logging system throws an exception. I am not sure if the exception originates from common.logging or log4net.

For example, I do:
string s = service.GetName();
log.Debug(m => m("servicename=" + s));

It appears this exception occurs because the string contains '{' and/or '}' characters. Can this be correct? (Maybe the name I get is "Service81{loc17}").

<log4net.Error>Exception rendering object type [Common.Logging.Factory.AbstractLogger+FormatMessageCallbackFormattedMessage]<stackTrace>System.FormatException: Input string was not in a correct format.
   at System.Text.StringBuilder.AppendFormat(IFormatProvider provider, String format, Object[] args)
   at System.String.Format(IFormatProvider provider, String format, Object[] args)
   at Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.FormatMessage(String format, Object[] args)
   at Alpha.Portal.ServiceAccess.Search.<>c__DisplayClass6.<AllContent>b__5(FormatMessageHandler m)
   at Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.ToString()
   at log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap rendererMap, Object obj, TextWriter writer)
   at log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter writer)</stackTrace></log4net.Error>

Thanks for any comments,
Peter

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Netcommon-developer mailing list
Net...@li...<mailto:Net...@li...>
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

Re: [Netcommon-developer] Common.Logging: : Input string was not in a correct format

[Stephen B. <sb...@gm...>]

Hmm...I have to agree that sounds like a Common.Logging issue after all --
thanks for your help in trying to better isolate the problem.  Can you open
an issue here
https://github.com/net-commons/common-logging/issues?state=open and we'll
try to look into it for you soon --?

Thanks again,

-Steve B.

Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen



On Fri, Dec 14, 2012 at 9:47 AM, Peter Kirk <pk...@al...> wrote:

>  Hi – thanks for your reply.****
>
> ** **
>
> If I try the following, then the failure occurs when passing the lambda
> expression to common.logging.****
>
> So log4net itself, and the non-lambda call to common-logging work fine.
> But when trying to pass the lambda, common-logging doesn’t like it.****
>
> ** **
>
> log4net.Config.XmlConfigurator.Configure(new FileInfo("log4net.config"));*
> ***
>
> log4net.ILog log4netLog = log4net.LogManager.GetLogger("TestApp");****
>
> ** **
>
> Common.Logging.ILog commonLog = Common.Logging.LogManager
> .GetCurrentClassLogger();****
>
> ** **
>
> log4netLog.Debug("log4net {a}");****
>
> commonLog.Debug("common logging {a}");****
>
> commonLog.Debug(m => m("common logging lambda {a}"));****
>
> ** **
>
> ** **
>
> /Peter****
>
> ** **
>
> ** **
>
> *From:* Stephen Bohlen [mailto:sb...@gm...]
> *Sent:* 14. december 2012 14:40
> *To:* Peter Kirk
> *Cc:* net...@li...
> *Subject:* Re: [Netcommon-developer] Common.Logging: : Input string was
> not in a correct format****
>
> ** **
>
> I am nearly certain that this issue is coming from Log4Net rather than
> Common.Logging.  Assuming this email contains your full stack trace, you
> can see this too by noting the root exception seems to originate from log4net.ObjectRenderer.RendererMap.FindAndRender(Object
> obj, TextWriter writer).
>
> IIRC in Log4Net the { } characters are used as replacement tokens in log
> message formatting strings and so are probably either reserved entirely or
> need to be escaped.  Common.Logging isn't doing any 'processing' of the log
> messages, merely passing them off to whatever logging framework you're
> using so I'd start there.  The simplest way to confirm this would probably
> be to try to wire up log4net to a test class of your own and forcibly try
> to process a log message like...
>
> log.Debug(m => m("this is a test with some { and } characters"));
>
> ...and see if log4net can handle that 'natively' using your same log4net
> configuration/logging format settings.
>
> Let us know if this helps~!
>
> -Steve B.****
>
>
> ****
>
> Steve Bohlen
> sb...@gm...
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen****
>
>
>
> ****
>
> On Fri, Dec 14, 2012 at 5:13 AM, Peter Kirk <pk...@al...> wrote:
> ****
>
> Hi, I am using common.logging (with log4net 1.2.10). Sometimes, when I try
> to log a string which I received from an external service, the logging
> system throws an exception. I am not sure if the exception originates from
> common.logging or log4net. ****
>
>  ****
>
> For example, I do:****
>
> string s = service.GetName();****
>
> log.Debug(m => m("servicename=" + s));****
>
>  ****
>
> It appears this exception occurs because the string contains ‘{‘ and/or
> ‘}’ characters. Can this be correct? (Maybe the name I get is
> "Service81{loc17}").****
>
>  ****
>
> <log4net.Error>Exception rendering object type
> [Common.Logging.Factory.AbstractLogger+FormatMessageCallbackFormattedMessage]<stackTrace>System.FormatException:
> Input string was not in a correct format.****
>
>    at System.Text.StringBuilder.AppendFormat(IFormatProvider provider,
> String format, Object[] args)****
>
>    at System.String.Format(IFormatProvider provider, String format,
> Object[] args)****
>
>    at
> Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.FormatMessage(String
> format, Object[] args)****
>
>    at
> Alpha.Portal.ServiceAccess.Search.<>c__DisplayClass6.<AllContent>b__5(FormatMessageHandler
> m)****
>
>    at
> Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.ToString()
> ****
>
>    at log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap
> rendererMap, Object obj, TextWriter writer)****
>
>    at log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj,
> TextWriter writer)</stackTrace></log4net.Error>****
>
>  ****
>
> Thanks for any comments,****
>
> Peter****
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer****
>
> ** **
>

Re: [Netcommon-developer] Common.Logging: : Input string was not in a correct format

[Stephen B. <sb...@gm...>]

I am nearly certain that this issue is coming from Log4Net rather than
Common.Logging.  Assuming this email contains your full stack trace, you
can see this too by noting the root exception seems to originate from
log4net.ObjectRenderer.RendererMap.FindAndRender(Object
obj, TextWriter writer).

IIRC in Log4Net the { } characters are used as replacement tokens in log
message formatting strings and so are probably either reserved entirely or
need to be escaped.  Common.Logging isn't doing any 'processing' of the log
messages, merely passing them off to whatever logging framework you're
using so I'd start there.  The simplest way to confirm this would probably
be to try to wire up log4net to a test class of your own and forcibly try
to process a log message like...

log.Debug(m => m("this is a test with some { and } characters"));

...and see if log4net can handle that 'natively' using your same log4net
configuration/logging format settings.

Let us know if this helps~!

-Steve B.

Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen



On Fri, Dec 14, 2012 at 5:13 AM, Peter Kirk <pk...@al...> wrote:

>  Hi, I am using common.logging (with log4net 1.2.10). Sometimes, when I
> try to log a string which I received from an external service, the logging
> system throws an exception. I am not sure if the exception originates from
> common.logging or log4net. ****
>
> ** **
>
> For example, I do:****
>
> string s = service.GetName();****
>
> log.Debug(m => m("servicename=" + s));****
>
> ** **
>
> It appears this exception occurs because the string contains ‘{‘ and/or
> ‘}’ characters. Can this be correct? (Maybe the name I get is
> "Service81{loc17}").****
>
> ** **
>
> <log4net.Error>Exception rendering object type
> [Common.Logging.Factory.AbstractLogger+FormatMessageCallbackFormattedMessage]<stackTrace>System.FormatException:
> Input string was not in a correct format.****
>
>    at System.Text.StringBuilder.AppendFormat(IFormatProvider provider,
> String format, Object[] args)****
>
>    at System.String.Format(IFormatProvider provider, String format,
> Object[] args)****
>
>    at
> Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.FormatMessage(String
> format, Object[] args)****
>
>    at
> Alpha.Portal.ServiceAccess.Search.<>c__DisplayClass6.<AllContent>b__5(FormatMessageHandler
> m)****
>
>    at
> Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.ToString()
> ****
>
>    at log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap
> rendererMap, Object obj, TextWriter writer)****
>
>    at log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj,
> TextWriter writer)</stackTrace></log4net.Error>****
>
> ** **
>
> Thanks for any comments,****
>
> Peter****
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>

[Netcommon-developer] Common.Logging: : Input string was not in a correct format

[Peter K. <pk...@al...>]

Hi, I am using common.logging (with log4net 1.2.10). Sometimes, when I try to log a string which I received from an external service, the logging system throws an exception. I am not sure if the exception originates from common.logging or log4net.

For example, I do:
string s = service.GetName();
log.Debug(m => m("servicename=" + s));

It appears this exception occurs because the string contains '{' and/or '}' characters. Can this be correct? (Maybe the name I get is "Service81{loc17}").

<log4net.Error>Exception rendering object type [Common.Logging.Factory.AbstractLogger+FormatMessageCallbackFormattedMessage]<stackTrace>System.FormatException: Input string was not in a correct format.
   at System.Text.StringBuilder.AppendFormat(IFormatProvider provider, String format, Object[] args)
   at System.String.Format(IFormatProvider provider, String format, Object[] args)
   at Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.FormatMessage(String format, Object[] args)
   at Alpha.Portal.ServiceAccess.Search.<>c__DisplayClass6.<AllContent>b__5(FormatMessageHandler m)
   at Common.Logging.Factory.AbstractLogger.FormatMessageCallbackFormattedMessage.ToString()
   at log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap rendererMap, Object obj, TextWriter writer)
   at log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter writer)</stackTrace></log4net.Error>

Thanks for any comments,
Peter

[Netcommon-developer] Common.Logging on NuGet Stable?

[Brendon M. <bwm...@gm...>]

Hi

Hope this isn't a repeat, although I had a quick look through the archive:


   1. Is the latest version of Common.Logging available on NuGet (currently
   2.1.1) considered stable - i.e. for possible production use? The project
   website states that 2.0 is the latest release - are only even minor
   versions stable?
   2. If the version on NuGet is not production ready, is there an
   estimated release date for 2.2?

Thanks!

Re: [Netcommon-developer] common logging configuration section reading on starting from network share failure

[Stephen B. <sb...@gm...>]

Interesting...we'll probably just change the core code so that we're
invoking the 'recommended workaround' code-path of
System.Configuration.Configuration.GetSection(sectionName)
instead of relying upon the ConfigurationManager to do the work.  Other
than this issue report, we've seen no additional issues reported from the
M1 milestone release bits so I think we'll go to 2.1 GA by the end of the
week after making this change.

Thanks for the reported issue!~

Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen


On Thu, May 31, 2012 at 9:25 AM, cosmin dumitru <du...@gm...> wrote:

> Hi,****
>
> ** **
>
> I have following problem found : Security exception on configuration
> reading when the application it is started from network share failure.****
>
> I try the basiclogging project using the EnterpriseLibrary ****
>
> ** **
>
> The only difference is that I use the outside definition of common logging
> configuration sections, that on local folder works without problems.****
>
> ** **
>
> <common>****
>
> <logging configSource="CommonLogging.Config" />****
>
> </common>****
>
> ** **
>
> The exception comes on
> return ConfigurationManager.GetSection(sectionName); in
> defaultconfigutrationreadder.cs.****
>
> The problem it is an bug in System.Configuration described in *
> http://support.microsoft.com/kb/2580188 *with workaround****
>
>  to use  System.Configuration.Configuration.GetSection(sectionName).****
>
> ** **
>
> I attach the exception analyze for an better overview. ****
>
> ** **
>
> Is any other case reported or any plan for the workaround integration ?***
> *
>
> ** **
>
> Regards,****
>
> Johannes Dumitru**
>
> ** **
>
> ** **
>

Re: [Netcommon-developer] Common.Logging 2.1 Timeline

[Stephen B. <sb...@gm...>]

Great -- thanks for the feedback~!

Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen


On Wed, May 30, 2012 at 7:26 AM, <as...@sz...> wrote:

> Dear Steve,
>
> I had a little spare time after the lunch and I tested your prerelease
> version whic was worked fine my little test console application.
>
> Best Regards,
> Attila.
>
> The app.config was:
> -------------------
> <?xml version="1.0"?>
> <configuration>
>  <configSections>
>    <sectionGroup name="common">
>      <section name="logging" type="Common.Logging.**ConfigurationSectionHandler,
> Common.Logging" />
>    </sectionGroup>
>    <section name="log4net" type="log4net.Config.**
> Log4NetConfigurationSectionHan**dler, log4net" />
>    <section name="deploy" type="NuGet.Deploy.**DeployConfigurationSection,
> NuGet.Deploy.Program" />
>  </configSections>
>  <common>
>    <logging>
>      <factoryAdapter type="Common.Logging.Log4Net.**Log4NetLoggerFactoryAdapter,
> Common.Logging.Log4Net1211">
>        <arg key="configType" value="INLINE" />
>      </factoryAdapter>
>    </logging>
>  </common>
>  <log4net debug="false">
>    <appender name="ApplicationLog" type="log4net.Appender.**
> RollingFileAppender">
>      <file type="log4net.Util.**PatternString"
> value="%property{PrgPath}/Log/**deploy_log.log" />
>      <appendToFile value="true" />
>      <maximumFileSize value="500KB" />
>      <rollingStyle value="Size" />
>      <maxSizeRollBackups value="10" />
>      <layout type="log4net.Layout.**PatternLayout">
>        <conversionPattern value="%d{yyyy.MM.dd. HH:mm:ss.fff} [%t] %-5p %c
> - %m%n" />
>      </layout>
>      <!-- levels: DEBUG, INFO, WARN, ERROR, FATAL -->
>      <filter type="log4net.Filter.**LevelRangeFilter">
>        <levelMin value="DEBUG" />
>        <levelMax value="FATAL" />
>      </filter>
>    </appender>
>    <appender name="ErrorLog" type="log4net.Appender.**
> RollingFileAppender">
>      <file type="log4net.Util.**PatternString"
> value="%property{PrgPath}/Log/**deploy_error.log" />
>      <appendToFile value="true" />
>      <maximumFileSize value="500KB" />
>      <rollingStyle value="Size" />
>      <maxSizeRollBackups value="10" />
>      <layout type="log4net.Layout.**PatternLayout">
>        <conversionPattern value="%d{yyyy.MM.dd. HH:mm:ss.fff} [%t] %c -
> %m%n" />
>      </layout>
>      <!-- levels: DEBUG, INFO, WARN, ERROR, FATAL -->
>      <filter type="log4net.Filter.**LevelRangeFilter">
>        <levelMin value="ERROR" />
>        <levelMax value="FATAL" />
>      </filter>
>    </appender>
>    <!-- levels: DEBUG, INFO, WARN, ERROR, FATAL -->
>    <root>
>      <level value="ALL"/>
>      <appender-ref ref="ApplicationLog" />
>      <appender-ref ref="ErrorLog"/>
>    </root>
>    <!-- logger name="NuGet.Deploy.**PhysicalFileSystem"
> additivity="false">
>      <level value="INFO"/>
>      <appender-ref ref="ErrorLog"/>
>    </logger -->
>  </log4net>
>  <deploy>
>    <mvc applicationSuffix=".**MvcApplication" applicationExtension=".dll"
> />
>    <wcf applicationSuffix=".Server.**Program" applicationExtension=".exe"
> />
>  </deploy>
>  <!-- runtime>
>    <assemblyBinding xmlns="urn:schemas-microsoft-**com:asm.v1">
>      <dependentAssembly>
>        <assemblyIdentity name="log4net" publicKeyToken="**1b44e1d426115821"
> culture="neutral" />
>        <bindingRedirect oldVersion="1.2.10.0" newVersion="1.2.11.0"/>
>      </dependentAssembly>
>    </assemblyBinding>
>  </runtime -->
>  <startup>
>    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.**0" />
>  </startup>
> </configuration>
>
>
> The result part of logfile:
> ---------------------------
>
> 2012.05.30. 13:19:22.323 [10] DEBUG NuGet.Deploy.Program -
> Wcf.ApplicationExtension=.exe
> 2012.05.30. 13:19:22.365 [10] DEBUG NuGet.Deploy.Program - Start checking
> values of the program parameters
> 2012.05.30. 13:19:22.365 [10] DEBUG NuGet.Deploy.Program - appType=Server
> 2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program - appName=NuGet
> 2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program - test=False
> 2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program - test2alive=True
> 2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program -
> slnDirectory=C:\RandaTFS\**Utility\NuGetMvcApplication
> 2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program -
> rootDirectory=C:\RandaTFS\**Utility\NuGetMvcApplication\**
> NuGet.Server.Program
> 2012.05.30. 13:19:22.367 [10] DEBUG NuGet.Deploy.Program -
> appDirectory=C:\RandaTFS\**Utility\NuGetMvcApplication\**
> NuGet.Server.Program\Bin\Debug
> 2012.05.30. 13:19:22.367 [10] DEBUG NuGet.Deploy.Program -
> appPath=C:\RandaTFS\Utility\**NuGetMvcApplication\NuGet.**
> Server.Program\Bin\Debug\**NuGet.Server.Program.exe
> 2012.05.30. 13:19:22.368 [10] DEBUG NuGet.Deploy.Program -
> nuSpecPath=C:\RandaTFS\**Utility\NuGetMvcApplication\**
> NuGet.Server.Program\Bin\**Debug\RB.Program.NuGet.Server.**nuspec
> 2012.05.30. 13:19:22.368 [10] DEBUG NuGet.Deploy.Program -
> versionAssemblyPath=C:\**RandaTFS\Utility\**NuGetMvcApplication\NuGet.**
> Server.Program\Bin\Debug\**NuGet.Common.dll
> 2012.05.30. 13:19:22.368 [10] DEBUG NuGet.Deploy.Program - Stop checking
> values of the program parameters
> 2012.05.30. 13:19:22.369 [10] INFO  NuGet.Deploy.Program - Phase 0 started
> 2012.05.30. 13:19:22.371 [10] DEBUG NuGet.Deploy.NuGetTools -
> NuPack(RB.Program.Lib.Server) started
> 2012.05.30. 13:19:22.376 [10] INFO  NuGet.Deploy.NuGetTools -
> RB.Program.Lib.Server.4.0.**30319.1.nupkg already exists
> 2012.05.30. 13:19:22.376 [10] DEBUG NuGet.Deploy.NuGetTools -
> NuPack(RB.Program.Lib.Server) stoped
> 2012.05.30. 13:19:22.380 [10] DEBUG NuGet.Deploy.NuGetTools -
> NuInstall(RB.Program.**NuGetTeszt.Server 1.0.4231.19312) started
> 2012.05.30. 13:19:22.382 [10] DEBUG NuGet.Deploy.NuGetTools -
> NuList(RB.Program.NuGetTeszt.**Server) started
> 2012.05.30. 13:19:22.382 [10] INFO  NuGet.Deploy.NuGetTools - NuGet
> 'list' started with RB.Program.NuGetTeszt.Server
> 2012.05.30. 13:19:23.144 [10] DEBUG NuGet.Deploy.NuGetTools - stdOut:
> No packages found.
> 2012.05.30. 13:19:23.144 [10] INFO  NuGet.Deploy.NuGetTools - NuGet
> 'list' succeded
> 2012.05.30. 13:19:23.144 [10] DEBUG NuGet.Deploy.NuGetTools -
> NuList(RB.Program.NuGetTeszt.**Server) stoped
> 2012.05.30. 13:19:23.144 [10] INFO  NuGet.Deploy.NuGetTools -
> Package(RB.Program.NuGetTeszt.**Server 1.0.4231.19312) not found in the
> gallery
> 2012.05.30. 13:19:23.144 [10] DEBUG NuGet.Deploy.NuGetTools -
> NuInstall(RB.Program.**NuGetTeszt.Server 1.0.4231.19312) stoped
> 2012.05.30. 13:19:23.144 [10] INFO  NuGet.Deploy.Program - Phase 0 stoped
>
>
>

Re: [Netcommon-developer] Common.Logging 2.1 Timeline

[<as...@sz...>]

Dear Steve,

I had a little spare time after the lunch and I tested your prerelease  
version whic was worked fine my little test console application.

Best Regards,
Attila.

The app.config was:
-------------------
<?xml version="1.0"?>
<configuration>
   <configSections>
     <sectionGroup name="common">
       <section name="logging"  
type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
     </sectionGroup>
     <section name="log4net"  
type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
     <section name="deploy"  
type="NuGet.Deploy.DeployConfigurationSection, NuGet.Deploy.Program" />
   </configSections>
   <common>
     <logging>
       <factoryAdapter  
type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter,  
Common.Logging.Log4Net1211">
         <arg key="configType" value="INLINE" />
       </factoryAdapter>
     </logging>
   </common>
   <log4net debug="false">
     <appender name="ApplicationLog"  
type="log4net.Appender.RollingFileAppender">
       <file type="log4net.Util.PatternString"  
value="%property{PrgPath}/Log/deploy_log.log" />
       <appendToFile value="true" />
       <maximumFileSize value="500KB" />
       <rollingStyle value="Size" />
       <maxSizeRollBackups value="10" />
       <layout type="log4net.Layout.PatternLayout">
         <conversionPattern value="%d{yyyy.MM.dd. HH:mm:ss.fff} [%t]  
%-5p %c - %m%n" />
       </layout>
       <!-- levels: DEBUG, INFO, WARN, ERROR, FATAL -->
       <filter type="log4net.Filter.LevelRangeFilter">
         <levelMin value="DEBUG" />
         <levelMax value="FATAL" />
       </filter>
     </appender>
     <appender name="ErrorLog" type="log4net.Appender.RollingFileAppender">
       <file type="log4net.Util.PatternString"  
value="%property{PrgPath}/Log/deploy_error.log" />
       <appendToFile value="true" />
       <maximumFileSize value="500KB" />
       <rollingStyle value="Size" />
       <maxSizeRollBackups value="10" />
       <layout type="log4net.Layout.PatternLayout">
         <conversionPattern value="%d{yyyy.MM.dd. HH:mm:ss.fff} [%t]  
%c - %m%n" />
       </layout>
       <!-- levels: DEBUG, INFO, WARN, ERROR, FATAL -->
       <filter type="log4net.Filter.LevelRangeFilter">
         <levelMin value="ERROR" />
         <levelMax value="FATAL" />
       </filter>
     </appender>
     <!-- levels: DEBUG, INFO, WARN, ERROR, FATAL -->
     <root>
       <level value="ALL"/>
       <appender-ref ref="ApplicationLog" />
       <appender-ref ref="ErrorLog"/>
     </root>
     <!-- logger name="NuGet.Deploy.PhysicalFileSystem" additivity="false">
       <level value="INFO"/>
       <appender-ref ref="ErrorLog"/>
     </logger -->
   </log4net>
   <deploy>
     <mvc applicationSuffix=".MvcApplication" applicationExtension=".dll" />
     <wcf applicationSuffix=".Server.Program" applicationExtension=".exe" />
   </deploy>
   <!-- runtime>
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
       <dependentAssembly>
         <assemblyIdentity name="log4net"  
publicKeyToken="1b44e1d426115821" culture="neutral" />
         <bindingRedirect oldVersion="1.2.10.0" newVersion="1.2.11.0"/>
       </dependentAssembly>
     </assemblyBinding>
   </runtime -->
   <startup>
     <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
   </startup>
</configuration>


The result part of logfile:
---------------------------

2012.05.30. 13:19:22.323 [10] DEBUG NuGet.Deploy.Program -  
Wcf.ApplicationExtension=.exe
2012.05.30. 13:19:22.365 [10] DEBUG NuGet.Deploy.Program - Start  
checking values of the program parameters
2012.05.30. 13:19:22.365 [10] DEBUG NuGet.Deploy.Program - appType=Server
2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program - appName=NuGet
2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program - test=False
2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program - test2alive=True
2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program -  
slnDirectory=C:\RandaTFS\Utility\NuGetMvcApplication
2012.05.30. 13:19:22.366 [10] DEBUG NuGet.Deploy.Program -  
rootDirectory=C:\RandaTFS\Utility\NuGetMvcApplication\NuGet.Server.Program
2012.05.30. 13:19:22.367 [10] DEBUG NuGet.Deploy.Program -  
appDirectory=C:\RandaTFS\Utility\NuGetMvcApplication\NuGet.Server.Program\Bin\Debug
2012.05.30. 13:19:22.367 [10] DEBUG NuGet.Deploy.Program -  
appPath=C:\RandaTFS\Utility\NuGetMvcApplication\NuGet.Server.Program\Bin\Debug\NuGet.Server.Program.exe
2012.05.30. 13:19:22.368 [10] DEBUG NuGet.Deploy.Program -  
nuSpecPath=C:\RandaTFS\Utility\NuGetMvcApplication\NuGet.Server.Program\Bin\Debug\RB.Program.NuGet.Server.nuspec
2012.05.30. 13:19:22.368 [10] DEBUG NuGet.Deploy.Program -  
versionAssemblyPath=C:\RandaTFS\Utility\NuGetMvcApplication\NuGet.Server.Program\Bin\Debug\NuGet.Common.dll
2012.05.30. 13:19:22.368 [10] DEBUG NuGet.Deploy.Program - Stop  
checking values of the program parameters
2012.05.30. 13:19:22.369 [10] INFO  NuGet.Deploy.Program - Phase 0 started
2012.05.30. 13:19:22.371 [10] DEBUG NuGet.Deploy.NuGetTools -  
NuPack(RB.Program.Lib.Server) started
2012.05.30. 13:19:22.376 [10] INFO  NuGet.Deploy.NuGetTools -  
RB.Program.Lib.Server.4.0.30319.1.nupkg already exists
2012.05.30. 13:19:22.376 [10] DEBUG NuGet.Deploy.NuGetTools -  
NuPack(RB.Program.Lib.Server) stoped
2012.05.30. 13:19:22.380 [10] DEBUG NuGet.Deploy.NuGetTools -  
NuInstall(RB.Program.NuGetTeszt.Server 1.0.4231.19312) started
2012.05.30. 13:19:22.382 [10] DEBUG NuGet.Deploy.NuGetTools -  
NuList(RB.Program.NuGetTeszt.Server) started
2012.05.30. 13:19:22.382 [10] INFO  NuGet.Deploy.NuGetTools - NuGet  
'list' started with RB.Program.NuGetTeszt.Server
2012.05.30. 13:19:23.144 [10] DEBUG NuGet.Deploy.NuGetTools - stdOut:
No packages found.
2012.05.30. 13:19:23.144 [10] INFO  NuGet.Deploy.NuGetTools - NuGet  
'list' succeded
2012.05.30. 13:19:23.144 [10] DEBUG NuGet.Deploy.NuGetTools -  
NuList(RB.Program.NuGetTeszt.Server) stoped
2012.05.30. 13:19:23.144 [10] INFO  NuGet.Deploy.NuGetTools -  
Package(RB.Program.NuGetTeszt.Server 1.0.4231.19312) not found in the  
gallery
2012.05.30. 13:19:23.144 [10] DEBUG NuGet.Deploy.NuGetTools -  
NuInstall(RB.Program.NuGetTeszt.Server 1.0.4231.19312) stoped
2012.05.30. 13:19:23.144 [10] INFO  NuGet.Deploy.Program - Phase 0 stoped

Re: [Netcommon-developer] Common.Logging 2.1 Timeline

[<as...@sz...>]

Dear Steve,

The 6/4/2012 is at the very near in the future, I look forward with  
excitement, thanks a lot your work!

Best Regards,
Attila.

Idézet (Stephen Bohlen <sb...@gm...>):

> Thanks for your interest.  Sorry we've not been able to get this out until
> just now (see https://nuget.org/packages/Common.Logging.Log4Net1211).  Its
> (temporarily) in a pre-release state for testing/eval purposes before we go
> 'GA' with it so you will need to set your nuget client to permit
> pre-release packages in order to consume this for now.  Please report any
> issues, etc. experiences.  If there are no issues reported in the next
> week, we will go RELEASE with this by Monday 6/4/2012.
>
> Thanks!
>
> Steve Bohlen
> sb...@gm...
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
>
>
> On Thu, Apr 26, 2012 at 3:44 AM, <as...@sz...> wrote:
>
>> Dear Developers,
>>
>> When do you publishing/issuing the new version ?
>>
>>
>> Thanks, Attila.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Netcommon-developer mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>>
>

[Netcommon-developer] Common.Logging 2.1 Timeline

[<as...@sz...>]

Dear Developers,

When do you publishing/issuing the new version ?


Thanks, Attila.

[Netcommon-developer] Common.Logging 2.1 Timeline

[Ed <cra...@gm...>]

In a previous thread around log4net 1.2.11, it was mentioned that 2.1 was
in progress.  I was wondering two questions



1)      Is there an ETA on that release?

2)      What other features will be included in 2.1?

a.       Specifically I’m very interested in logging context and was
wondering if that was going to be included.


Thank you!

-Ed

Re: [Netcommon-developer] Common.Logging.Log4Net NuGet packages broken

[Erich E. <eei...@gm...>]

I named my doormat Rob Grabowsky

Sent from my iPhone

On 7 Feb 2012, at 22:01, Mark Pollack <mpo...@vm...> wrote:

> Thanks...where can we get log4j voodoo dolls?
> Mark
> 
> Sent from my iPhone
> 
> On Feb 7, 2012, at 1:59 PM, Stephen Bohlen <sb...@gm...> wrote:
> 
>> Just FYI, the Common.Logging.Log4net package on NuGet has now been corrected to reflect the dependency on Log4Net 1.2.10 *specifically* so it should work again now without any necessary post-referencing modifications.  Support for Log4Net 1.2.11 is in progress and will be released as soon as its ready (probably as part of the upcoming Common.Logging 2.1).
>> 
>> Regards,
>> 
>> Steve Bohlen
>> sb...@gm...
>> http://blog.unhandled-exceptions.com
>> http://twitter.com/sbohlen
>> 
>> 
>> On Fri, Feb 3, 2012 at 8:10 AM, Stephen Bohlen <sb...@gm...> wrote:
>> We are also in the process of having the NuGet team transition 'ownership' of the Common.Logging.* NuGet packages over to the proper members of the Common.Logging team so that we can upload a corrected Common.Logging.Log4Net (1.2.10) package to replace the one that is presently posted on NuGet.  It turns out that despite the package showing members of this team as 'owners', these packages were apparently initially posted by a helpful member of the community rather than any of the Common.Logging committers and so we need to be made 'owners' of the packages in order to maintain them.
>> 
>> The NuGet team is working now to correct this, after which time we will be able to both correct the now-problematic Log4Net package as well as upload new versions of Common.Logging.* packages that are presently under development with formal support for Log4Net 1.2.11 as well as several other logging frameworks (EntLib5, etc.).
>> 
>> 
>> Thanks --!
>> 
>> Steve Bohlen
>> sb...@gm...
>> http://blog.unhandled-exceptions.com
>> http://twitter.com/sbohlen
>> 
>> 
>> On Tue, Jan 31, 2012 at 3:16 PM, Bruno Baia <br...@gm...> wrote:
>> Until we release a new version, here is a tip to force nuget to use 1.2.10:
>> 
>> In your packages.config file, update the log4net line with:
>> <package id="log4net" version="1.2.10" allowedVersions="[1.2.10]"/>
>> 
>> 
>> - Bruno
>> 
>> 2012/1/10 Jeffrey Becker <jef...@gm...>
>> I'm not sure if anyone on this list is responsible for the NuGet packages for Common.Logging but the developers are not contactable through the NuGet form.   
>> 
>> The Common.Logging.Log4Net package is currently broken.  Specifically the package is configured to require log4net >= 1.2.10 which will cause nuget to install the latest log4net (1.2.11) even if 1.2.10 is already installed.  I was able to fix the issue temporarily using a bindingRedirection in my app.config.  However, I've put a large amount of effort into eliminating my need for app.config and would like to be able to go back to deploying without one.
>> 
>> 
>> ------------------------------------------------------------------------------
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>> 
>> _______________________________________________
>> Netcommon-developer mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> 
>> _______________________________________________
>> Netcommon-developer mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Netcommon-developer mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer

Re: [Netcommon-developer] Common.Logging.Log4Net NuGet packages broken

[Mark P. <mpo...@vm...>]

Thanks...where can we get log4j voodoo dolls?
Mark

Sent from my iPhone

On Feb 7, 2012, at 1:59 PM, Stephen Bohlen <sb...@gm...> wrote:

> Just FYI, the Common.Logging.Log4net package on NuGet has now been corrected to reflect the dependency on Log4Net 1.2.10 *specifically* so it should work again now without any necessary post-referencing modifications.  Support for Log4Net 1.2.11 is in progress and will be released as soon as its ready (probably as part of the upcoming Common.Logging 2.1).
> 
> Regards,
> 
> Steve Bohlen
> sb...@gm...
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
> 
> 
> On Fri, Feb 3, 2012 at 8:10 AM, Stephen Bohlen <sb...@gm...> wrote:
> We are also in the process of having the NuGet team transition 'ownership' of the Common.Logging.* NuGet packages over to the proper members of the Common.Logging team so that we can upload a corrected Common.Logging.Log4Net (1.2.10) package to replace the one that is presently posted on NuGet.  It turns out that despite the package showing members of this team as 'owners', these packages were apparently initially posted by a helpful member of the community rather than any of the Common.Logging committers and so we need to be made 'owners' of the packages in order to maintain them.
> 
> The NuGet team is working now to correct this, after which time we will be able to both correct the now-problematic Log4Net package as well as upload new versions of Common.Logging.* packages that are presently under development with formal support for Log4Net 1.2.11 as well as several other logging frameworks (EntLib5, etc.).
> 
> 
> Thanks --!
> 
> Steve Bohlen
> sb...@gm...
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
> 
> 
> On Tue, Jan 31, 2012 at 3:16 PM, Bruno Baia <br...@gm...> wrote:
> Until we release a new version, here is a tip to force nuget to use 1.2.10:
> 
> In your packages.config file, update the log4net line with:
> <package id="log4net" version="1.2.10" allowedVersions="[1.2.10]"/>
> 
> 
> - Bruno
> 
> 2012/1/10 Jeffrey Becker <jef...@gm...>
> I'm not sure if anyone on this list is responsible for the NuGet packages for Common.Logging but the developers are not contactable through the NuGet form.   
> 
> The Common.Logging.Log4Net package is currently broken.  Specifically the package is configured to require log4net >= 1.2.10 which will cause nuget to install the latest log4net (1.2.11) even if 1.2.10 is already installed.  I was able to fix the issue temporarily using a bindingRedirection in my app.config.  However, I've put a large amount of effort into eliminating my need for app.config and would like to be able to go back to deploying without one.
> 
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> 
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
> 
> 
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> 
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
> 
> 
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer

Re: [Netcommon-developer] Common.Logging.Log4Net NuGet packages broken

[Stephen B. <sb...@gm...>]

Just FYI, the Common.Logging.Log4net package on NuGet has now been
corrected to reflect the dependency on Log4Net 1.2.10 *specifically* so it
should work again now without any necessary post-referencing
modifications.  Support for Log4Net 1.2.11 is in progress and will be
released as soon as its ready (probably as part of the upcoming
Common.Logging 2.1).

Regards,

Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen


On Fri, Feb 3, 2012 at 8:10 AM, Stephen Bohlen <sb...@gm...> wrote:

> We are also in the process of having the NuGet team transition 'ownership'
> of the Common.Logging.* NuGet packages over to the proper members of the
> Common.Logging team so that we can upload a corrected
> Common.Logging.Log4Net (1.2.10) package to replace the one that is
> presently posted on NuGet.  It turns out that despite the package showing
> members of this team as 'owners', these packages were apparently initially
> posted by a helpful member of the community rather than any of the
> Common.Logging committers and so we need to be made 'owners' of the
> packages in order to maintain them.
>
> The NuGet team is working now to correct this, after which time we will be
> able to both correct the now-problematic Log4Net package as well as upload
> new versions of Common.Logging.* packages that are presently under
> development with formal support for Log4Net 1.2.11 as well as several other
> logging frameworks (EntLib5, etc.).
>
>
> Thanks --!
>
> Steve Bohlen
> sb...@gm...
> http://blog.unhandled-exceptions.com
> http://twitter.com/sbohlen
>
>
> On Tue, Jan 31, 2012 at 3:16 PM, Bruno Baia <br...@gm...> wrote:
>
>> Until we release a new version, here is a tip to force nuget to use
>> 1.2.10:
>>
>> In your packages.config file, update the log4net line with:
>> <package id="log4net" version="1.2.10" allowedVersions="[1.2.10]"/>
>>
>>
>> - Bruno
>>
>> 2012/1/10 Jeffrey Becker <jef...@gm...>
>>
>>> I'm not sure if anyone on this list is responsible for the NuGet
>>> packages for Common.Logging but the developers are not contactable through
>>> the NuGet form.
>>>
>>> The Common.Logging.Log4Net package is currently broken.  Specifically
>>> the package is configured to require log4net >= 1.2.10 which will cause
>>> nuget to install the latest log4net (1.2.11) even if 1.2.10 is already
>>> installed.  I was able to fix the issue temporarily using a
>>> bindingRedirection in my app.config.  However, I've put a large amount of
>>> effort into eliminating my need for app.config and would like to be able to
>>> go back to deploying without one.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Write once. Port to many.
>>> Get the SDK and tools to simplify cross-platform app development. Create
>>> new or port existing apps to sell to consumers worldwide. Explore the
>>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>>> http://p.sf.net/sfu/intel-appdev
>>>
>>> _______________________________________________
>>> Netcommon-developer mailing list
>>> Net...@li...
>>> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>>
>> _______________________________________________
>> Netcommon-developer mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>>
>>
>

Re: [Netcommon-developer] Common.Logging.Log4Net NuGet packages broken

[Stephen B. <sb...@gm...>]

We are also in the process of having the NuGet team transition 'ownership'
of the Common.Logging.* NuGet packages over to the proper members of the
Common.Logging team so that we can upload a corrected
Common.Logging.Log4Net (1.2.10) package to replace the one that is
presently posted on NuGet.  It turns out that despite the package showing
members of this team as 'owners', these packages were apparently initially
posted by a helpful member of the community rather than any of the
Common.Logging committers and so we need to be made 'owners' of the
packages in order to maintain them.

The NuGet team is working now to correct this, after which time we will be
able to both correct the now-problematic Log4Net package as well as upload
new versions of Common.Logging.* packages that are presently under
development with formal support for Log4Net 1.2.11 as well as several other
logging frameworks (EntLib5, etc.).

Thanks --!

Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen


On Tue, Jan 31, 2012 at 3:16 PM, Bruno Baia <br...@gm...> wrote:

> Until we release a new version, here is a tip to force nuget to use 1.2.10:
>
> In your packages.config file, update the log4net line with:
> <package id="log4net" version="1.2.10" allowedVersions="[1.2.10]"/>
>
>
> - Bruno
>
> 2012/1/10 Jeffrey Becker <jef...@gm...>
>
>> I'm not sure if anyone on this list is responsible for the NuGet packages
>> for Common.Logging but the developers are not contactable through the NuGet
>> form.
>>
>> The Common.Logging.Log4Net package is currently broken.  Specifically the
>> package is configured to require log4net >= 1.2.10 which will cause nuget
>> to install the latest log4net (1.2.11) even if 1.2.10 is already installed.
>>  I was able to fix the issue temporarily using a bindingRedirection in my
>> app.config.  However, I've put a large amount of effort into eliminating my
>> need for app.config and would like to be able to go back to deploying
>> without one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>>
>> _______________________________________________
>> Netcommon-developer mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>>
>>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>

Re: [Netcommon-developer] Common.Logging.Log4Net NuGet packages broken

[Bruno B. <br...@gm...>]

Until we release a new version, here is a tip to force nuget to use 1.2.10:

In your packages.config file, update the log4net line with:
<package id="log4net" version="1.2.10" allowedVersions="[1.2.10]"/>


- Bruno

2012/1/10 Jeffrey Becker <jef...@gm...>

> I'm not sure if anyone on this list is responsible for the NuGet packages
> for Common.Logging but the developers are not contactable through the NuGet
> form.
>
> The Common.Logging.Log4Net package is currently broken.  Specifically the
> package is configured to require log4net >= 1.2.10 which will cause nuget
> to install the latest log4net (1.2.11) even if 1.2.10 is already installed.
>  I was able to fix the issue temporarily using a bindingRedirection in my
> app.config.  However, I've put a large amount of effort into eliminating my
> need for app.config and would like to be able to go back to deploying
> without one.
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>

Re: [Netcommon-developer] Common.Logging.Log4Net NuGet packages broken

[Stephen B. <sb...@gm...>]

We will be both correcting the existing package (Common Logging 2.0) to
reflect its dependency *only* on Log4Net 1.2.10 and releasing a new Common
Logging 2.1 package as soon as its ready (with proper support for Log4Net
1.2.11).

Thanks --!

Steve Bohlen
sb...@gm...
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen


2012/1/11 <as...@sz...>

> Dear Team,
>
> I would like to ask you (too) please build a new separated issue for
> 1.2.11.
>
> Thanks,
> Attila.
>
>
> Idézet (Jeffrey Becker <jef...@gm...>):
>
> > I'm not sure if anyone on this list is responsible for the NuGet packages
> > for Common.Logging but the developers are not contactable through the
> NuGet
> > form.
> >
> > The Common.Logging.Log4Net package is currently broken.  Specifically the
> > package is configured to require log4net >= 1.2.10 which will cause nuget
> > to install the latest log4net (1.2.11) even if 1.2.10 is already
> installed.
> >  I was able to fix the issue temporarily using a bindingRedirection in my
> > app.config.  However, I've put a large amount of effort into eliminating
> my
> > need for app.config and would like to be able to go back to deploying
> > without one.
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>

Re: [Netcommon-developer] log4net Version=1.2.11.0

[<as...@sz...>]

Dear Daniel,

I misunderstand you first I thought that ServiceStack is part of Log4Net!
Oh, yes I can see in ServiceStack the ServiceStack.Interfaces.dll is  
the abstraction layer!

But because I use Quartz.Net which is based on Common.Logging I would  
like to use that in my project.

Possible in my future project I will try ServiceStack.

Thanks your adjustment,
Attila.

Idézet ("Harman, Daniel A" <dan...@jp...>):

> What do you mean it's placed into one dll? Are they are merging  
> assemblies or something?
>
> For others reference, the project is here:  
> https://github.com/ServiceStack/ServiceStack.Logging
>
>
> Kind regards
>
> Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10  
> Aldermanbury, London, EC2V 7RF | T: +44 (0) 207 742 6565 | F: +44  
> (0)207 325 3722 | dan...@jp... | jpmorgan.com
>
>
> -----Original Message-----
> From: as...@sz... [mailto:as...@sz...]
> Sent: 12 January 2012 07:24
> To: net...@li...
> Subject: Re: [Netcommon-developer] log4net Version=1.2.11.0
>
> Hi,
>
>> It's worth noting that servicestack now have a similar logging
>> abstraction component. Not tried it yet, but may be worth
>> consideration.
>
> Because Log4Net is placed into one DLL I can not see that abstarction
> layer as Common.Logging.dll.
>
> Attila.
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of
> securities, accuracy and completeness of information, viruses,
> confidentiality, legal privilege, and legal entity disclaimers,
> available at http://www.jpmorgan.com/pages/disclosures/email.
>

Re: [Netcommon-developer] log4net Version=1.2.11.0

[Harman, D. A <dan...@jp...>]

What do you mean it's placed into one dll? Are they are merging assemblies or something?

For others reference, the project is here: https://github.com/ServiceStack/ServiceStack.Logging


Kind regards

Daniel A Harman | VP | Delta1/PT RAD | J.P. Morgan | 10 Aldermanbury, London, EC2V 7RF | T: +44 (0) 207 742 6565 | F: +44 (0)207 325 3722 | dan...@jp... | jpmorgan.com


-----Original Message-----
From: as...@sz... [mailto:as...@sz...] 
Sent: 12 January 2012 07:24
To: net...@li...
Subject: Re: [Netcommon-developer] log4net Version=1.2.11.0

Hi,

> It's worth noting that servicestack now have a similar logging  
> abstraction component. Not tried it yet, but may be worth  
> consideration.

Because Log4Net is placed into one DLL I can not see that abstarction  
layer as Common.Logging.dll.

Attila.



------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

Re: [Netcommon-developer] log4net Version=1.2.11.0

[<as...@sz...>]

Hi,

> It's worth noting that servicestack now have a similar logging  
> abstraction component. Not tried it yet, but may be worth  
> consideration.

Because Log4Net is placed into one DLL I can not see that abstarction  
layer as Common.Logging.dll.

Attila.

Re: [Netcommon-developer] Common.Logging.Log4Net NuGet packages broken

[<as...@sz...>]

Dear Team,

I would like to ask you (too) please build a new separated issue for 1.2.11.

Thanks,
Attila.


Idézet (Jeffrey Becker <jef...@gm...>):

> I'm not sure if anyone on this list is responsible for the NuGet packages
> for Common.Logging but the developers are not contactable through the NuGet
> form.
>
> The Common.Logging.Log4Net package is currently broken.  Specifically the
> package is configured to require log4net >= 1.2.10 which will cause nuget
> to install the latest log4net (1.2.11) even if 1.2.10 is already installed.
>  I was able to fix the issue temporarily using a bindingRedirection in my
> app.config.  However, I've put a large amount of effort into eliminating my
> need for app.config and would like to be able to go back to deploying
> without one.
>