Enabling the SharePoint Safe Mode Call Stack, Disabling Custom Errors and Enabiling Compilation Debugging

When developling for SharePoint, I find myself always turning on the call stack and disabiling the custom errors in my development environment. It really does help when trying to debug run-time problems. I know there a few posts out there that describe how to do this, but I figured I would repost it as a reference for myself (which you are welcome to use).

Just remember that I do this in my development environment only. I don’t recommend changing the web.config files in any other environment.

Enabling the Call Stack

Set the value CallStack attribute in the SafeMode element in the web.config file to true.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <configuration>
  ...
  <SharePoint>
   <SafeMode MaxControls="200"
             CallStack="true"
             DirectFileDependencies="10"
             TotalFileDependencies="50"
             AllowPageLevelTrace="false">
    ...
   </SafeMode>
   ...
 </SharePoint>
 ...
</configuration>

Disabling Custom Errors

Set the value of the mode attribute in the customErrors element to Off.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <configuration>
  ...
  <system.web>
   ...
   <customErrors mode="Off" />
   ...
  </system.web>
 ...
</configuration>

Enabiling Compilation Debugging

Set the value of the debug attriute in the compilation element to true.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <configuration>
  ...
  <system.web>
   ...
   <compilation debug="true">
    ...
   </compilation>
   ...
  </system.web>
 ...
</configuration>

 Putting it all together

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <configuration>
  ...
  <SharePoint>
   <SafeMode MaxControls="200"
             CallStack="true"
             DirectFileDependencies="10"
             TotalFileDependencies="50"
             AllowPageLevelTrace="false">
    ...
   </SafeMode>
   ...
 </SharePoint>
 <system.web>
   ...
   <customErrors mode="Off" />
   ...
   <compilation debug="true">
    ...
   </compilation>
   ...
  </system.web>
 ...
</configuration>
Fork me on GitHub

Daniel Larson’s Best Practices for Elevated Privilege in SharePoint

[via Daniel Larson]

Daniel Larson, a MOSS MVP, has been ranting over the past few days about the use of the SPSecurity.RunWithElevatedPrivileges method. While I have been amused with his rants, I share his concerns and frustrations as a result of using the method in my SharePoint development experience and seeing the method abused and missused in many code reviews. Today, he posted a list of his best practices for gaining “elevated privileges” SharePoint.

Daniel Larson’s list of best practives for elevated privileges in SharePoint:

  • Avoid using SPSecurity.RunwithElevatedPrivilege to access the SharePoint object model. Instead, use the SPUserToken to impersonate with SPSite.
  • If you do use SPSecurity.RunwithElevatedPrivilege, dispose of all objects in the delegate. Do not pass SharePoint objects out of the RunwithElevatedPrivilege  method.
  • Only use SPSecurity.RunwithElevatedPrivilege to make network calls under the application pool identity. Don’t use it for elevation of privilege of SharePoint objects.
  • Always use the SPSite constructor with an SPUserToken to create an elevated privilege security context in SharePoint. To impersonate the system, use the SystemAccount.UserToken property of the current SPSite context, such as:
    var site = new SPSite(SPContext.Current.Site.ID,  SPContext.Current.Site.SystemAccount.UserToken);
  • Avoid passing SharePoint objects between different security contexts (SPSite instances), with the exception of the SPUserToken used in the SPSite ctor. An SPUser object created from SPSite A cannot (reliably) be passed to SPSite B. This can be the source of obscure bugs in production that are difficult to reproduce in development. For example, an SPUser reference created from SPContext.Current.Site cannot reliably be used in an elevated site context, as the user reference may take on a different meaning in the alternate context.
  • Never use elevated privilege to bypass security– always use it to work with security.
  • Restrict what assemblies can use elevated privilege by running in minimal trust, avoiding the GAC, and auditing any CAS policies deployed with vendor solutions.

Upcoming Conferences

Two conferences were announced last week that I want to share with you:

PDC2008 [via Andrew Connell] – Regristration for the Microsoft Professional Developers Conference 2008 is now open and is scheduled to take place in Los Angeles on October 27-30 at the Los Angeles Convention Center.

SharePoint Best Practices and Governance Conference [via Bill English] – The conference has been announced and will be taking place in Washington DC on September 15-17.

I would like to attend both of these, but I am not sure if I will be able to.

Setting up a SharePoint Development Environment to Support Silverlight Development

[via Andrew Connell]

This morning Andrew Connell held a webcast introducing ASP.NET developers to Silverlight development for SharePoint. The webcast is the third in a series of webcasts to help ASP.NET developers get primed for SharePoint development. After the webcast Andrew was kind enough to post the steps he took in preparing his SharePoint development environment for Silverlight development.

I wonder if it is possible to create a solution file to deploy the Silverlight 2 Beta 1 DLL and make the necessry configuration changes to the web.config file to make the set up of the environment easier? I might have to try that.

SharePoint Utilities and Tools

Here are some updates and announcements regarding tools and utilities for SharePoint: