Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
add comment

6 Answers

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).

share|improve this answer
1  
Also, the ULS can write the the Windows Event Logs, which can then be monitored. –  Andy Burns Aug 9 '11 at 13:26
    
did you put in place an easier way for the admin (or a developer) to go through the logs, a web app (something like elmah has). I speak about a production environement –  SPFan Aug 9 '11 at 13:47
    
there are plenty of tools available; ULS Viewer and SPDiag being the most useful IMO –  Wictor Wilen MCA MCM MVP Aug 9 '11 at 15:24
    
Another question related to reading the logs sharepoint.stackexchange.com/questions/10865/… –  Kit Menke Aug 9 '11 at 15:29
1  
Log to the ULS. You can do it with a single line of code or you can create a (small) wrapper class to do it (with custom "Prodcts" in the log so you can separate them out). The ULS log viewer is a great tool because you can monitor each server in real-time and see what's coming from ULS. Don't reinvent the wheel with log4net or some other logging system (and definately not Enterprise Library, that's overkill). –  Bil Simser Aug 9 '11 at 15:34
add comment

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/

share|improve this answer
add comment

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/

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

+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.

enter image description here

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.