SharePoint【调试，诊错系列】-- 使用ULS Log跟踪Solution错误信息

   在开发Sharepoint Solution时，我们可以使用Attach to process来Debug我们的方案，然而一旦我们把Solution部署到了生产机上，我们就难以再使用这个最直接的方法了，如果Solution出错，我们就需要足够的手段来获取尽量明细的错误信息，USL log(Unified Logging Service)则为我们提供了一条途径来帮助我们定位用户的跟踪信息。在早期的Sharepoint2007中,虽然也有ULS随着一起发布，但我们却不能使用它，这在SharePoint2007的SDK 中明确说明了这点，它仅限于内部使用。到了SharePoint 2010则改变了这一切，我们现在也可以在我们的代码中使用它来写入我们需要捕获的跟踪信息了。
   请新建一个Sharepoint项目，在项目中创建一个Visual Web Part，如下

 

在按钮的Click后台代码中写入(需要引入 Microsoft.SharePoint.Administration)

        protected void btnLogin_Click(object sender, EventArgs e)
        {
            try { var i = 0; var a = 2 / i; }
            catch (Exception ex) { LoggingService.LogError("WebParts", ex.Message); }
        }

 Built 此项目并部署到测试网站，然后运行WebPart上的Button的Click事件，就会有错误信息写到ULS log中 (请在目录

\Program files\Common Files\Microsoft Shared\Web Server Extensions\14\Logs 下去找相关Log, 默认情况下，跟踪log名由计算机名加上日期和时间信息组成,文件类型为“文本文档”。),通常你可以使用SharePoint ULS Log Viewer打开对应的Log文件可以看到错误事件记录如下(你也可以用微软提供的ULSViewer来查看,它的用法会有一些不同):

  你会注意到，在打开的Log文件中，对应的按钮事件的报错记录的Area区域值为Unkown，如果我们有多个Solution部署到服务器上，这会让我们很难识别到底是哪个Solution注册的错误，因此我们需要进一步改进我们的作法，所以,请在原项目中新创建一个类，此类继承自SPDiagnosticsServiceBase基类，如下图

此类的定义代码如下

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.Administration; //需要引入


namespace CopyListContent
{
    public class LoggingService : SPDiagnosticsServiceBase
    {
        public static string MyDiagnosticAreaName = "MyDiagnosticTest";
        private static LoggingService _Current;
        public static LoggingService Current
        {
            get
            {
                if (_Current == null)
                { _Current = new LoggingService(); }
                return _Current;
            }
        }

        private LoggingService()
            : base("MyDiagnosticTest Logging Service", SPFarm.Local)
        { }

        protected override IEnumerable<SPDiagnosticsArea> ProvideAreas()
        {
            List<SPDiagnosticsArea> areas = new List<SPDiagnosticsArea>  {            
                new SPDiagnosticsArea(MyDiagnosticAreaName, new List<SPDiagnosticsCategory>
                {new SPDiagnosticsCategory("WebParts", TraceSeverity.Unexpected, EventSeverity.Error) })};
            return areas;
        }

        public static void LogError(string categoryName, string errorMessage)
        {
            SPDiagnosticsCategory category = LoggingService.Current.Areas[MyDiagnosticAreaName].Categories[categoryName];
            LoggingService.Current.WriteTrace(0, category, TraceSeverity.Unexpected, errorMessage);
        }
    }

}

在此类中，我们在Area区域写入了我们当前Solution的标识名"MyDiagnosticTest"，重新修改按钮事件的定义，引用我们上面定义的类来写入ULS log

protected void btnLogin_Click(object sender, EventArgs e)
        {
            try { var i = 0; var a = 2 / i; }
            catch (Exception ex) 
            { SPDiagnosticsService.Local.WriteTrace(0, 
                new SPDiagnosticsCategory("My Category", TraceSeverity.Unexpected, EventSeverity.Error), 
                TraceSeverity.Unexpected, ex.Message, ex.StackTrace); 
            }
        }

重新Built Solution并部署运行，回到ULS log中用SharePoint ULS Log Viewer查看，可以看到如下

我们可以通过识别Area字段来更加容易的找到属于我们的Solution写入的报错信息了。当然你还可以灵活的组织你需要写入的内容从而方便你更加容易地定位Solution的用户跟踪信息。

   需要注意的是，对于Sandbox Solution,我们是无法直接写跟踪信息到ULS中的，我们只能通过Full-Trust Proxy来把跟踪信息写入到ULS中，Full-Trust Proxy的使用请参见:

Sharepoint学习笔记---Sandbox Solution-- Full Trust Proxy--开发步骤

Sharepoint学习笔记---Sandbox Solution-- Full Trust Proxy--开发实例之(1、创建一个能访问DataBase的Full Trust Proxy)

Sharepoint学习笔记---Sandbox Solution-- Full Trust Proxy--开发实例之(2、在Webpart中访问Full Trust Proxy)

  还有一点需要注意的是，针对Sandbox的Solution，对于发生在其中的Unhandled Exception都会消费掉Usage point(资源消费记数)，所以，如何处理里面的异常，如何设定系统对此Sandbox Solution的消费限制都需要你提前进行考量。