Adding copious amounts of logging to custom projects is a good idea for developers because it helps track down problems when they occur. However, there will always be times when errors still occur that developers will have to track down. In addition, developers may want to change some of the default system pages that SharePoint 2010 uses. The following sections describe these two scenarios. Using the Web Application web.config File
When errors occur in an ASP.NET application, they are shown either in their raw state (when the web.config file contains the element <customErrors mode="Off" />), or by using a custom error page to hide the details of the error and display a custom message (when the web.config file contains the element <customErrors mode="On" />).
The default configuration in SharePoint 2010 is to turn custom errors on and not show the details of the error. One reason for this is so users do not see unfriendly errors, and instead are presented with a more graceful error page. Another reason for not including the full details is because providing complete details of an error could be considered a security flaw as it may expose more information that should be exposed to users.
Unfortunately, the custom error messages delivered by SharePoint are sometimes not detailed enough for developers to troubleshoot the problem. When building custom solutions, it is helpful to see the full error including the specific exception, the exception message, and the complete call stack. This can be achieved easily by modifying the web application's web.config file and changing the mode in the <customErrors /> element to Off. This will display the raw ASP.NET error page for the entire web application. This process can also be automated by using a web application–scoped Feature, by implementing the Feature's activated and deactivated events to make this change, as shown in the following example.
C#
*********************************************************************************
public override void FeatureActivated(SPFeatureReceiverProperties properties) {
SPWebApplication WebApp = (SPWebApplication)properties.Feature.Parent;
foreach (ModificationEntry modEntry in Entries) {
WebApp.WebConfigModifications.Add(
CreateModification(modEntry)
);
}
WebApp.WebService.ApplyWebConfigModifications();
}
public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {
SPWebApplication WebApp = (SPWebApplication)properties.Feature.Parent;
foreach (ModificationEntry modEntry in Entries) {
WebApp.WebConfigModifications.Remove(
CreateModification(modEntry)
);
}
WebApp.WebService.ApplyWebConfigModifications();
}
private struct ModificationEntry {
public string Name;
public string XPath;
public string Value;
public SPWebConfigModification.SPWebConfigModificationType ModType;
// Parameterized contructor.
public ModificationEntry(
string Name, string XPath, string Value,
SPWebConfigModification.SPWebConfigModificationType ModType) {
// Intialize structure instances.
this.Name = Name;
this.XPath = XPath;
this.Value = Value;
this.ModType = ModType;
}
}
private ModificationEntry[] Entries = {
new ModificationEntry(
"mode", "configuration/system.web/customErrors", "Off",
SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute)
};
private SPWebConfigModification CreateModification(ModificationEntry modEntry) {
// Create and return SPWebConfigModification object.
SPWebConfigModification modification;
modification = new SPWebConfigModification(modEntry.Name, modEntry.XPath);
modification.Owner = "MSDN.SharePointDebugger";
modification.Sequence = 0;
modification.Type = modEntry.ModType;
modification.Value = modEntry.Value;
return modification;
}
*********************************************************************************
Using the Layouts web.config File
You should keep in mind that folders in a web application inherit the web.config file settings from their parent folders, unless they are overwritten by a local web.config file. Specific to SharePoint 2010, the http://.../_layouts folder contains its own web.config file that has the custom errors turned on. Therefore, when creating custom application pages or troubleshooting the SharePoint 2010 application pages, developers may want to either modify the web.config located in the {SharePoint Root}\TEMPLATE\LAYOUTS folder, or add a custom web.config that turns off custom errors in the folder containing the custom application pages.
From http://msdn.microsoft.com/en-us/library/gg512103.aspx#bk_sperrlog
