1) Delegate control:

• A delegate control defines a region in an aspx page that allows the content to be
replaced with our custom content.
• This custom content will be created via a SharePoint feature, and when feature is
deployed and activated, replaces the standard content at runtime.
Example:
• The Global Navigation bar is located at the top of all the pages in a site, and the
master page uses a delegate control in a placeholder to determine what to
render at runtime. Here is the markup for the delegate control:
<SharePoint:DelegateControl runat="server" ControlId="GlobalNavigation"/>
• Note that the ControlId value determines what delegate control is, so for our
example the Global Navigation bar has a ControlId value of GlobalNavigation.
• Once we know the name of the delegate control we are working with, we are
ready to write code for our delegate control.
Procedure:
• Open Visual Studio 2010 and create a new Empty SharePoint project.
• Map a folder to the CONTROLTEMPLATES directory in the SharePoint root (the 14
hive).
• Add a new SharePoint 2010 User Control by right-mouse clicking the
CONTROLTEMPLATES mapped directory, from the Solution Explorer. (Only in
SharePoint 2010)
• Give the user control an appropriate name (I named it
ucGlobNavDelegateControl).
• Once the control is created, open it in the Designer and add some markup:

• You will also need to create an Elements.xml file, so add a module to the project,
which will create the Elements.xml file as part of it (you can delete the
Sample.txt file created).

• Delete the markup between the Elements tags, and add the following markup:
<Control Id = "GlobalNavigation" Sequence="90"
ControlSrc="~/_ControlTemplates/ucGlobNavDelegateControl.ascx" />
• This markup associates the delegate control we are creating with the delegate
control placeholder defined in the master pages in a SharePoint site collection.
 • Note that the ControlId value equals GlobalNavigation, which specifies that our
custom delegate control is overriding the Global Navigation control.
• The Sequence value must be less than 100, since SharePoint will render the
control with the lowest sequence (the default control is set at 100).
• The ControlSrc value indicates the location to our custom delegate control.
• Deploying our custom delegate control is done using a feature, so create a
feature in Visual Studio and name it MyCustGlobalNavFeature.
• Add the module you created to it.
<Feature xmlns="http://schemas.microsoft.com/sharepoint/" Id="373042ED-718D-
46e2-9596-50379DA4D522"
Title="COB.Demos.DelegateControls"
Description="Specifies which user control should be used for the 'PageHeader'
DelegateControl used on the site master page. The replacement user control is stored in
the CONTROLTEMPLATES directory." Scope="Farm"
Hidden="FALSE"
Version="1.0.0.0">
<ElementManifests>
<ElementManifest Location="elements.xml"/>
</ElementManifests>
</Feature>
• Wrap the feature as a solution, since solution packages can also deploy files. To
deploy the .ascx file along with the solution, your solution manifest file should
look something like:
<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="E8694626-
60F8-4d07-9140-8F9F634020DE">
<FeatureManifests>
<FeatureManifest Location="COB.Demos.DelegateControls\feature.xml" />
</FeatureManifests>
<TemplateFiles>
<TemplateFile Location="CONTROLTEMPLATES\COBPageHeader.ascx" />
</TemplateFiles>
</Solution>
• These files would now all be packaged as a solution (.wsp) in the usual way with
makecab.exe.
 • When the solution is deployed, the file will be copied to the right place on all the
web front-ends in your farm, and when the feature is activated SharePoint will
know that it should henceforth load ucGlobNavDelegateControl.ascx for any
Delegate Control with an ID of GlobalNavigation.
• Parameters can be passed to the control via the declaration on the page. To read
these, the control's implementation should walk up the control tree to get the
values. An example would be:
<SharePoint:DelegateControl runat="server" ControlId="PageHeader"
MyParam="MyValue"> </SharePoint:DelegateControl>
• By adding AllowMutiple="true" to the declaration, you can make the Delegate
Control load more than one user/server control.

http://digsharepoint.blogspot.in/2012/02/what-is-delegate-controls-in-
sharepoint.html
http://www.sharepointnutsandbolts.com/2007/06/using-delegate-control.html
2) ULS:
http://msdn.microsoft.com/en-us/library/
gg193966.aspx#MonitoringSharePoint2010_Intro
• The Unified Logging Service (ULS) is the service that is responsible for keeping an eye
on SharePoint and reporting what it finds. It can report events to three different
locations:

i. SharePoint trace logs

ii. Windows Event Log

iii. SharePoint logging database

• Where the event is logged (and if it's logged at all) depends on the type of
event, as well as how SharePoint is configured. The ULS is a passive service,
which means that it only watches SharePoint and reports on it; it never acts
on what it sees.

i) Trace Logs:
• It is a primary mechanism to write SharePoint Foundation events to the SharePoint
Trace Log, and stores them in the file system at below location

• By default, trace logs are located in the LOGS directory of the SharePoint root (also
called the 14 Hive) at

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14.

 • So, ULS logs are also referred to as Trace Logs.

• By ensuring that useful information is written to the trace log, many issues that arise
in development can be resolved without attaching a debugger.

• Another advantage of ULS logging for developers is that problems encountered in

the UI or notifications do not need to be displayed in the UI. Instead they can be
written to the database for administrators and developers to review and analyze.

• In Microsoft SharePoint Foundation 2010 the preferred method of writing to the

Trace Logs is to use the SPDiagnosticsBase class, specifically the WriteTrace() and
[WriteEvent()] methods.

Below example shows how to use the object model to write directly to the
Trace Log.
using Microsoft.SharePoint.Administration;

try

//throw new Exception(“Test USL LOGS”);

catch (Exception ex)

SPDiagnosticsService diagSvc = SPDiagnosticsService.Local; //Gets an object that represents

the instance of the Diagnostics Service that is currently running in the server farm.

diagSvc.WriteTrace(0,

new SPDiagnosticsCategory("My Category", TraceSeverity.Unexpected, EventSeverity.Error),

TraceSeverity.Unexpected,

ex.Message,

ex.StackTrace);//Writes a trace to the Microsoft SharePoint Foundation trace log.

=> Parameters:
i) id: Type: System.UInt32
 The application-defined identifier for the trace.

ii) category:

Type: Microsoft.SharePoint.Administration.SPDiagnosticsCategory

• The category of the trace which contains the TraceSeverity and EventSeverity
properties for a specific category.

• TraceSeverity specifies the level of trace information that is written to the trace log
file.

Member
name Description

None Writes no trace information to the trace log file.

Represents an unexpected code path and actions that

Unexpected should be monitored.

Represents an unusual code path and actions that

Monitorable should be monitored.

High Writes high-level detail to the trace log file.

Medium Writes medium-level detail to the trace log file.

Verbose Writes low-level detail to the trace log file.
• EventSeverity Indicates the severity of events written to the Windows event log.

EventSeverity
type Description

None Indicates no event entries are written.

ErrorCritical Indicates a problem state that needs the immediate attention of an administrator.
Error Indicates a problem state requiring attention by a site administrator.
 Indicates conditions that are not immediately significant but that may eventually cause
Warning failure.
Information Contains noncritical information provided for the administrator.
Verbose Writes low-level detail to the trace log file.

iii) severity:

Type: Microsoft.SharePoint.Administration.TraceSeverity

The severity of the trace.

When writing a trace log by using the ULS API, you must specify a severity level. The severity
level is displayed in the ULS trace log and is commonly used by reporting or filtering tools.
For this reason, it is important to choose an appropriate level.

iv) output:

Type: System.String

The message.

v) data

Type: System.Object[]

The optional items to be replaced into the message format string.

• Below example shows how to use the object model to write directly to the
event Log.
using Microsoft.SharePoint.Administration;

try

//throw new Exception(“Test USL LOGS”);

catch (Exception ex)

SPDiagnosticsService diagSvc = SPDiagnosticsService.Local; //Gets an object that represents

the instance of the Diagnostics Service that is currently running in the server farm.

diagSvc.WriteEvent(0,

new SPDiagnosticsCategory(“Add Category”, TraceSeverity.Monitorable, EventSeverity.Error),

EventSeverity.Monitorable,
ex.Message,

ex.StackTrace);//Writes a entry to the event log.

Difference between event log and trace log:

• The event log is what you can view with the Event viewer. It can also contain events
from other sources besides Project Server and SharePoint.

• A trace log contains only information on your specific product, in this case Project
Server and SharePoint.

• When troubleshooting I always start with the event logs in the Event viewer and use
a trace log for more detailed information