SP2010 Logging Summary

Overview: ULS & Logging can be confusing for SharePoint.  It's really pretty simple and this post aims to clarify the basics of error logging on SP2010 farms.

Tip: Usage records analytics (referred to as Web Analytics).  Usage and ULS logs as well as other metrics and the event log are put into the Reporting database that is configured in "CA" under "monitoring" for "Configure Usage and health data collection".  This post only looks at ULS.

Summary:

1. Each event in SharePoint is given a unique correlationId, this is a unique identifier to help pull out the appropriate log entries from the ULS. 
2. ULS create .log files that can be opened individually using notepad.
3. ULSViewer is useful for examining multiple log files at once.  There are a few products that do the same thing but I use the Microsoft ULSViewer.
4. The amount of information logged by the ULS can be set in CA or using PS (see image 1 below).
5. If you enable timer jobs ("Diagnostic Data Provider: xxx" * 7), the data is shipped from the ULS logs on each server into the SP Logging DB.  Useful as it provides a central view and you can backup/achieve the data.  The Timer jobs pull in data from ULS, EventViewer, Timer Jobs and various other performance indicators.

Image 1.  Amending the default logging settings using PowerShell  (Can also use CA)

  

More Info:
Setting Logging levels: http://technet.microsoft.com/en-us/library/ff607887
Debugging & Logging: http://msdn.microsoft.com/en-us/library/gg512103.aspx
Logging explained by Waldek: http://blog.mastykarz.nl/logging-uls-sharepoint-2010/
ULS Explained: http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2011/07/07/sharepoint-2010-cookbook-the-usage-of-sharepoint-2010-uls-logging.aspx
ULS Viewer by Spencer Harbar: http://www.harbar.net/archive/2010/10/06/ulsviewer-ndash-the-tool-that-no-sharepoint-practitioner-should-be.aspx

Creating a shared logging block

Overview:  A client host multiple applications on there SharePoint on premise farm and these need to be logged consistanly.

Hypothesis:  SP2010 provide easy logging ability to the ULS, Microsoft have the SharePoint Best Practices that includes the assemblies for logging, these can be extended to create a easy re-useable set of logging functions.  Key areas to cover are where are you logging to: ULS, Event Viewer.  Sandbox solution can be logged to ULS and the event viewer using a full trust proxy solution.  SharEPoint Online will need to log to a list on the hosted farm.

Microsofts Patterns and Practices code library for SharePoint 2010, is useful for providing the core logging functionality.  The Parrerns and Practices can be extended so the custom method for all application on the farm would call the logging code block that is hosted in the GAC.

More Info:
http://technet.microsoft.com/en-us/library/ee748656.aspx
http://blog.mastykarz.nl/logging-uls-sharepoint-2010/
http://www.alexangas.com/blog/2011/09/intro-to-sharepoint-2010-patterns-practices-logging/
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23919

Updated 28 May 2020:
For C#, Power Platform, React, .... I advise to use: App Insights or https://serilog.net/
Log4Net is still very common

Retrieving Publishing Columns using a CAML Query

Overview: LINQ is easy and strongly type however, occasionally we need to get data in an optimised fashion or LINQ won't do the job i.e. inefficient queries, Publishing fields and we need to revert to a CAML query.

Code Example:

Explanation:

1. Perform a CAML query, U2U still works on SP2010 and I use it to work out my CAML query.
2. Add code that performs the query, optimise it (you don't need every field returned by CAML, you can look at the query results without the "ViewFieldOnly" & "IncludeMadatoryFields" setting and you will see how many fields are returned which for big queries isn't good).
3. Using the SPListItem retrieve the field data from the publishing fields.

Andrew Connell explains how to extend SPMetal
Tobias Zimmergrin's blog has good Linq to SharePoint 2010 info, his blog on showing the CAML generated by LINQ to SharePoint queries is invaluable to work out what SPMetal is generating.
Update: 09/10/2010 Extend SPMetal to retrieve list attachments

Update 27/10/2010 - A re-hash of Tobias Zimmergrin's blog describing retrieving the CAML generated by a LINQ to sharePoint Query.

Logging custom error for SharePoint 2010 custom code

Problem: SP2010 has good logging in the ULS logs. Unlike MOSS you can write to the ULS logs in SharePoint 2010, allowing for a single consistant place to log your errors. The event viewer logs errors to a lesser extent than ULS where administrators tend to look first. However, on all projects the topic of how and where to log custom coding errors comes up. What level should the event be caught at and where should they be placed. I have seen multiple was of doing this and it really comes down to what the previous projects used and how do you want to monitor errors.
Tips:

1. Don't write code to function using error catching i.e. I have seen developers catch a specific error and from this position they know the code is to follow specific logic -it's very inefficient. Write code to deal with all situations.
2. Catch errors as specifically as possible, then decide if the error should be bubbled up or can it be dealt with via the logs. But catch the appropriate errors so they are logged.
3. You can write to Unified Logging Service(ULS) logs but these are often not checked or hard to find issues you have thrown up in your code, so consider using a logging block such as Microsoft's Enterprise Logging blocks or Log4net. Ted Pattison suggests writing to ULS and he know his stuff so if you don't have another specified logging policy write to the ULS. And if you do have another logging method consider writing to the ULS anyway.
4. There are a lot of logging applications for .NET, and most companies tend to have logging code ready for implementation on your SP 2010 project.
5. I have seen a MS gold partner use tracing on all projects. So when an error occurs they turn on tracing and try replicate the issue in production environments. Far better to catch errors so you can get your issues resolved quickly and don't need to change config setting or leave tracing enabled on the live production boxes.
6. A web part error can cause an entire page to throw an application error. However don't throw try catch blocks around all code, rather try catch the errors at more appropriate junctions such as at the service layer. Once again it really depends on the WP.

Summary: Avoid using errors for logic (pretty obvious). Log the errors to a distinct area (database, file system(xml files are pretty useful)) to identifying where and what the issue is. Catch specific errors -try not to catch general exceptions and if you do need to catch general exceptions make sure you have looked for more specific exceptions such nullrefobjectexceptions.

More Info:
MSDN SharePoint Logger - http://msdn.microsoft.com/en-us/library/ff798361.aspx
Writing to the ULS
Update: 5 Dec 2010 - Writing to ULS using SP2010 by Waldek Mastykarz
Update: 18 Jab 2011 - MSDN article on logging and debugging

The SharePoint Logger
using Microsoft.Practices.ServiceLocation;ILogger logger = SharePointServiceLocator.GetCurrent().GetInstance();
using Microsoft.Practices.SharePoint.Common.ServiceLocation;
using Microsoft.Practices.SharePoint.Common.Logging;
IServiceLocator serviceLocator = SharePointServiceLocator.GetCurrent();
ILogger logger = serviceLocator.GetInstance();
logger.TraceToDeveloper("Unexpected condition");

Update 14 Dec 2010 - ULS Viewer - Tool to view ULS log and filter data
Update 23 Dec 2010 - Tracing using CorrelationId