On Jul 3, 10:29 am, "R. K. Wijayaratne" <rasi...@gmail.comwrote:
This is the primary scenario that I was thinking of. Lets say that
there is a library (the server code in this case), which has logging
built into it, that is shipped to many different 3rd party clients.
Some of the clients may not want to use logging at all for their
purpose and some may want to use their own custom logging mechanism,
which is not compatible with the shipped library's logging mechanism.
So they are essentially stuck with a logging solution which they don't
want to or can't utilize, which is hanging around inside the library's
compiled code and adding weight to it. This is unless it can be
compiled out of the code before the library is shipped. However in
this case it may take longer to design and build this ability into the
library.
On the other hand, if they *do* want logging and you've shipped them a
library that has no logging facilities, they're completely out of
luck.
Many logging libraries are very flexible - if you've already got a
logging solution and you want Log4Net to use it, you can easily write
an adapter, for instance. You configure the logging in a file rather
than hard-coding the configuration, and you're away.
Yes, there's the extra dependency on log4net.dll - no great issues.
Yes, there's still a performance hit even if you don't log - but it's
tiny.
The costs involved in the situation where you don't want any logging
but logging is available are small. The problems created by not having
any logging where you *do* want some are massive.
Jon