What's your favorite logger when creating SharePoint apps ? I'm using log4net for ex. but I want to know what other software programmers use when building all type of sharepoint apps and why ?!.

6 Answers 6


log4net if my personal choice and our company standard. very simple to use.


Mike has a good blog post here


With ULS logs usually because:

  • it doesn't require extra library - so easier to get approval from client)
  • cleans up after itself
  • easily filter what's being logged via Central Admin view

What do you use to actually view them?

  • Notepad is fine, but big log files are a PITA! Especially when you want to filter by a process or category or watch in real-time.
  • The web viewer extensions for Central Admin is OK, but slow. Most of the viewers only allow you to look at one log file, not a rolling one.
  • SPTraceView is awesome for real time tray pings of errors as they happen.

A more detailed comparison of logging approaches is on the SharePointDevWiki.com


Enterprise libraries logging! We created a small footprint addon that is simple to use. Advantages are that you can use it as instrumentation for SCOM / MOM and hence treat SharePoint like any other mission critical application. ULS logging IMO tends to be harder to find and harder to read, and does not go well with monitoring tools.


I'm using the SharePoint Logging Library at the moment and I'm finding it a great blend of function/flexability.

It has built in methods for logging the start and end of methods and different levels of logging. And to get started all you need to do is add an assembly/using reference and away you go.

It writes all the logs to the ULS log which from a development perspective I find is great.

Anyways saw this question and just thought I'd throw in my 2c.


I currently use ULS logging and prefer it right now. It cleans up after itself and administrators can configure how long logs are kept for through the UI. All logging relating to SharePoint is stored in one location which gives context when an error in my code is caused by a problem in the product itself. The downside is all of those log messages lumped together, but there are many "viewer" tools out there that help with this.

I've used log4net and Enterprise Library as well which were OK. They both worked pretty similarly, although EntLib was a nightmare to configure and unreliable in my experience. The big advantage with these is that you can e-mail critical errors as well as log to a database, etc. I only had problems with multiple apps logging to the same file (e.g. a web part plus a console app at the same time) where there were locking problems.

  • OK, but if the app is on client server and client reports bugs. Is more easy for client to send you only the logs generated by your app (by email), right ?! This is one reason why I do prefer to have log files separated. Oct 9, 2009 at 15:15
  • That's a good point, although it's not unusual to need the full SP logs as well. Pros and cons to each!
    – Alex Angas
    Oct 9, 2009 at 16:03

ULS logs for Server errors - for the reasons given above. It's simple, unified, and already there. Better logging would be good, though.

For client apps - it depends. Log4NET is good, though I've had some issues with in and Office plug-ins I've written.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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