A delegate control is a SharePoint control which allows you to show different content in a predefined master page area on different sites, webs, etc.
SharePoint comes with a set of predefined delegate controls, but of course you can add your own ones to the master page if the existing ones don’t satisfy your needs.
If you’d like to override a delegate control then you’ll need a feature to do so. In your feature you need to add a Control element to your XML, like the following:
<Control Id=”IdOfTheDelegateControl” Sequence=”100” ControlSrc=”/_ControlTemplates/Mycontrol.ascx” />
Or you can specify a control from an assembly, like so:
<Control Id=”IdOfTheDelegateControl” Sequence=”100” ControlClass=”MyControl” ControlAssembly=”Assembly.MyControls” />
You can also set properties on your controls in the XML definition:
There’s one property I haven’t mentioned yet, the AllowMultipleControls. As its name suggests it renders all the controls specified in different levels in the delegate control, ordering by the Sequence property. If you don’t set it (the default is false) then the override with the lowest Sequence number will be rendered on the page.
You can read more about delegate controls at MSDN.
This topic is close particularly close to my heart, since my job is filled with debugging web parts. The first thing you should note is that in ASP.NET, there’s a customErrors section in the web.config files. However hard you set it to false in every imaginable level SharePoint will override it, and shows its useless “Oops, exception, I won’t tell you anything about it” form. Unless you set callStack attribute of the SharePoint element in the very same web.config file to true.
But of course serving error messages with call stack is not the most user friendly way of showing that something went wrong. SharePoint provides a nice logging infrastructure. The key player is the ULS (Unified Logging System) log. You can find it in the 14/ folder of your SharePoint installation, under the log folder. Although you’ll be much better using the free ULS Viewer tool.
SharePoint logs a great deal of information to this log by default. For example, unhandled exceptions which bubble up to the UI are all logged here. But you can use this log programmatically, too. You can use the SPDiagnosticsService class to write your events to the ULS logs, or roll out your custom logging implementation by subclassing the SPDiagnosticsServiceBase class.
SharePoint 2010 has a component called the Developer Dashboard which is very similar to ASP.NET tracing. By default, it’s turned off, so you have to use stsadm or PowerShell to make it appear. There are two modes of operation: On displays the dashboard icon on every page, so anyone with rights to the page can view its output on every page. There’s another mode called OnDemand, which displays an icon on every page, on which you can access the dashboard information. By default the dashboard records a variety of instrumental information, but of course you can add your own informations to it. You have to wrap your all your custom components you’d like to display in SPMonitoredScopes. Here’s a quick code:
using (var scope = new SPMonitoredScope(“My long running method”))
//Your code here.
Now run time information will be available on the dashboard for you.