SharePoint Study Notes-debug & troubleshooting-use ULS log to track solution error messages

When developing SharePoint solution, we can use attach to process to debug our solution. However, once we deploy solution on the production machine, it is difficult for us to use this most direct method, if a solution error occurs, we need sufficient means to obtain the detailed error information as far as possible) this provides us with a way to help us locate User tracking information. In the early release of sharepoint2007, although ULS was also released together, we could not use it, which was clearly stated in the sharepoint2007 SDK and was only used internally. In SharePoint 2010, all of this is changed. Now we canCodeTo write the tracing information we need to capture.
Create a Sharepoint project and create a visual web part in the project.

Write in the button's click background code (Microsoft. Sharepoint. administration is required)

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 this project is deployed to the test website, and then run the button click event on the webpart, an error message will be written to the ULS log (in the directory

\ Program Files \ common files \ microsoft shared \ Web Server Extensions \ 14 \ logs. By default, the trace log name consists of the computer name, date, and time information, the file type is "Text Document ".), Generally, you can use SharePoint ULS Log Viewer to open the corresponding log file and you can see the following error event records (you can also use the ulsviewer provided by Microsoft to view them. Its usage is somewhat different ):

You will notice that in the open log file, the area value of the corresponding button event error record is unkown. If we have multiple solutions deployed on the server, this makes it difficult for us to identify the solution registration error. Therefore, we need to further improve our practice. Therefore, create a new class in the original project that inherits from the spdiagnosticsservicebase base class, for example

The definition code of this class is as follows:

Using System;
Using System. Collections. Generic;
Using System. LINQ;
Using System. text;
Using Microsoft. Sharepoint. administration; // Need to introduce

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;
}
}

PrivateLoggingservice ()
: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 VoidLogerror (StringCategoryname,StringErrormessage)
{
Spdiagnosticscategory Category = loggingservice. Current. areas [mydiagnosticareaname]. categories [categoryname];
Loggingservice. Current. writetrace (0, Category, traceseverity. Unexpected, errormessage );
}
}

}

In this class, we have written our current solution Identification name "mydiagnostictest" in the area, re-modified the button event definition, and referenced the class we defined above to write the 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 );
}
}

Re-built solution and deploy and run it. Return to the ULS log and use the SharePoint ULS Log Viewer to view it. You can see the following:

We can identify the area field to easily find the error message written by our solution. Of course, you can also flexibly organize the content you need to write so that you can easily locate the User tracking information of solution.

It should be noted that for sandbox solution, we cannot directly write the tracing information to ULS. We can only write the tracing information to ULS through full-trust proxy, for the use of full-trust proxy, see:

SharePoint Study Notes --- sandbox solution -- full trust proxy -- development steps

SharePoint Study Notes --- sandbox solution -- full trust proxy -- Development Instance (1. Create a full trust proxy that can access the database)

SharePoint Study Notes --- sandbox solution -- full trust proxy -- Development Instance (2. Access full trust proxy in webpart)

Note that for the sandbox solution, the unhandled exception will consume the usage point (resource consumption count, you must consider how to set the consumption limit for sandbox solution in advance.