Should I use a third-party logging framework?

Question

I was wondering if any of you were using an extra logging framework like elmah or log4net?

Isn't logging already done by SharePoint (ULS)?

If you think that it can be useful, could you explain why?

Answer 1

Logging to the ULS is the best way IMHO, it's an extensible framework and you can create your own categories. There are good examples of this in the P&P Guidance for SharePoint (spg.codeplex.com).

Answer 2

We are using the SharePoint Guidance Library from MS Patterns & Practices - both for 2007 and 2010 projects. The SPG Library contains an excellent interface implementation of a Logging framework which is decoupled from your custom code by a Service Locator pattern making the unit testing so much easier.

The SPG Library delivers a configuration framework as well and it can be extended to use your own custom Interface implementations.

When it comes to logging it melts very well into the 2010 model for creating custom diagnostics areas and write to both eventlog (operations monitors this already!) and the ULS log.

See the codeplex site for more info: http://spg.codeplex.com/

Answer 3

I agree with Wictor - ULS with custom categories is the best approach. But besides that I would also recommend to abstract away the SharePoint specifics in a simple custom logging framework. One that can be configured with different logging targets like files and of course the SharePoint ULS log. Alternatively, extend Log4Net with a ULS log appender.

This approach is worth considering if you also need to do logging in your shared .NET class libraries that are not specific to SharePoint but might be referenced and used in SharePoint projects. In such libraries you do not want to know anything about the SharePoint SPDiagnosticsService class. Generally, code should just log and not care about where the log entries end up. This is configuration. In my code I just have statements like:

log.Error(...)
log.Warning(...)
log.Info(...)
log.Verbose(...)

where each method have different overloads to accept Exceptions and string formatting parameters. Using this approach, your entire code base can easily log to the ULS log in a SharePoint context and to files in another.

Answer 4

By extending SPDiagnosticsService you get a simple logger fully integrated with SharePoint which can log to both the Event and ULS log. You are also able to set logging levels on different categories in Central Admin.

I would not recommend to use any third party tools like log4net for logging in SharePoint since logging is well supported already.

// ULS Logging
LoggingService.WriteTrace(Constants.MyCategory, TraceSeverity.Medium, "...");

// Windows Event Log
LoggingService.WriteEvent(Constants.MyCategory, EventSeverity.Information, "...");

A fully working example is found here (incl. VS project): http://www.parago.de/2011/01/how-to-implement-a-custom-sharepoint-2010-logging-service-for-uls-and-windows-event-log/

Answer 5

I have implemented log4net custom logging in my recent project. Since I wanted simple logging framework and I used log4net in some other non SharePoint projects this looked like best option.

To set log4net and SharePoint to work together is a challenge (I wanted to deploy it in feature without making changes to web.config file). It can be done and here is link to get you started: http://www.codeproject.com/KB/sharepoint/SharepointLog4Net.aspx

Personally I like log4net and I have used it a lot (non SharePoint projects) but I must admit there are some issues on SharePoint with log file locking, there are some limits in configuration (eg. log file path is hard coded) and logging from custom TimerJobs is tricky.

Answer 6

+1 for ULS. But if you use Enterprise Library (or one of its components) it also provides very flexible and easy way to configure logging.