Logging in a C# library

Question

All,

I wonder what is the best practise regarding logging inside a library. I am creating a C# library to be used by users and at some points I want to log an error or a warning. Is it a good practice to use log4net and log in a file?

Thanks,

M

Answer 1

The beauty of using log4net is that your library doesn't have to specify where something is logged. The destination (log appenders) of the log messages is determined by the configuration, which is specified by the application (typically in a config file).

So yes, use log4net following their recommended patterns (a unique "logger" per class) and inform your users that your library uses log4net. Any log messages that your library code generates will be routed according to the consumers configuration (file, database, console, trace, etc).

EDIT: Here is a good short primer on log4net that explains the basic concepts.

Answer 2

log4net is just a 3rd party library, its not best practice that you must use that as your logging library when using C#. My advice would be always persist the log to somewhere (most common being a text file). However, there is also the event log (requires a little extra setup).

I tend to use NLog which I find is very easy to use and simple to setup, it actually uses log4net behind the scenes. As for logging inside your class libraries its really just which ever approach you feel is best for your application. Some people would create 1 logger and pass it down into the classes, others would create a separate logger per loggable class. I tend to create a static logger per class and it works fine.

Answer 3

I use log4net in my own library but I would not do this if my library should be used by others (i.e. outside of my organization). In that case I would use an interface for logging, provide a default implementation based on log4net in separate assembly and use one way or another to allow the users of the library to inject their own implementation.

Having said this: I really like log4net and would not use anything else, but I think it is wrong to force others to have to use the logging framework of your choice.

Edit:

• I would also not consider it good practice having the library log to a file by default. The users of your library should be able to decide where log messages end-up.
• I would also provide a "no-operation" implementation that can be used if no logging at all is required. This probably should be default behavior an not require any additional assemblies or steps to implement.

Answer 4

It depends on what you want to do.

Do you want to have a logging mechanism for pure technical stuff that you can switch on/off with varying verbosity (for support activities)? Or do you want to log more business related stuff that is intended to be read by the users of your library?

You should answer these questions first, then you can decide upon what to log, where to store it, and how to format it...

In any case, log4net is a good, mature and stable logging framework for all these purposes. And to log to a rolling file is common practice (but by far not the only option...).

Regards Thomas

Answer 5

What are your users using for logging?
This is the question which you need to answer to determine the right framework.
Log4net is powerful and relatively easy from my pov. You could also use it to log into a streamwriter if there is nothing else specified.

Answer 6

Practice vise a good way to do it is to introduce a Logging facade, so you don't care about the logger you use, you have a consistent common interface for the logger.

for e.g you could try this or simply write your own.

Answer 7

When you want to log information inside a reusable framework, best is not to depend on any particular logging framework. You have two choices.

1. Use a logging facade, such as Common.Logging
2. Or use your own mechanism that users can hook to.

For point 2. You can think of the way LINQ to SQL allows registering a TextWriter to the DataContext.Log property. Or you can allow users to configure some logger with a configuration construct that is supplied by your framework. This can be simple or complex. A more complex one is by using the .NET provider pattern to allow users to route logging to their own provider. When you want to do this, look at this provider pattern template for Visual Studio.