Sterling International Consulting Group

SharePoint 2013 and SharePoint 2010 Developers Tips

Email | Print

For most developers, working with SharePoint in production environments can be quite a mystery. If you’ve ever been hit in the head from behind and turn to see nothing, that’s kind of the feeling. When something goes wrong within a SharePoint site it can be extremely difficult to track down and unfortunately SharePoint doesn’t really help.

Part of this is the robust error handling within SharePoint itself – it does its best to mask out errors and prevent the site from suffering due to a problem with a specific component, tile or web part.  The other part is the biggest challenge developer’s face: SharePoint site and content security. This is the biggest mistake most make; since they develop in an environment where they are the Administrator, security issues are missed. If something isn’t tested properly using the lowest permissions, it can be really frustrating to determine what is happening. 


Rule 1: Always test your code using accounts that have the same permissions that your end users will have in production – if they will only have Read access, plan accordingly!

For most, production is a ‘blind eye’ test. If something fails, you can try to search the System Application Event log or check the SharePoint ULS (Universal Log System) Log using the Correlation ID shown on the error page. This is sort of the hunt and peck approach – you might get lucky, but then again, you might not.

There are several tools and options available to help reduce these issues and while they might not fix the problem right away, they will help you track it down much faster. Be aware – only three of these methods (writing to the ULS logs, using Fiddler and IE’s F12) will be of any help in a production environment.

Let’s start with the simplest one – you have a web part or sandbox solution and there’s a problem that is crashing the page. First thing is to get it off the page so end-users don’t suffer. So if your page URL is something like http://myspsite/pages/default.aspx, simply add “?contents=1” to the end of the URL, as in http://myspsite/pages/default.aspx?contents=1. 

This will display the Web Part Maintenance Page:



As you can see, you have the options to Close* (NEVER DO THAT), reset, and delete – if your solution has a problem, DELETE IT. If you CLOSE it, it will still run on the page in the background and that won’t help anything!

* NOTE: Closing web parts is a very bad thing unless it is intentional. While ‘Closed’ (not on the page), they are still loaded and run like those displayed. Effects of this can vary – from driving you crazy while debugging to causing SharePoint search to take up too much CPU. If you accidentally close one, you can re-add it by clicking Add a Web Part in any zone – the closed part will be listed under the “Closed” category.

Another way to get to this page is through the Pages library itself – if you open the page and edit the properties, you will see a link to the page at the bottom:


Writing to SharePoint ULS Log

Rule 2: Always use the SharePoint ULS Logs to write out warnings and errors (and use it for debug if necessary).

Most developers overlook what they can do themselves –that is, write messages directly to the SharePoint log. This is better than the System Event Log since it is pretty likely you won’t have the permissions to do so. However, from the SharePoint context, you can write to the log at will. 

This does not however, guarantee that the SharePoint administrator will give you access to those logs – however, your case for this is simple: without them it is impossible to debug problems in production. In my shop recommendations, developers should have full access to System, SQL, and SharePoint logs – there is no benefit to ‘hiding them’ (or having to beg the admin for them).

Rule 3: Get agreement with the admin to get the logs if needed!

Using the SharePoint ULS logs is quite easy – in your SharePoint Project, 

1) Add a reference to Microsoft.Office.Server

2) Use the ‘try / catch’ error handling logic to write out exceptions (errors) to the log where you can include the message and the stack trace:



…some code here…


catch (Exception ErrDetected)


// Write out the exception:

Microsoft.Office.Server.Diagnostics.PortalLog.LogString(“Exception – {0} – {1} – {2}”,

“Error detected in…”,




3) You can also use it so simply write out status messages to keep track of where you are in the code:

Microsoft.Office.Server.Diagnostics.PortalLog.LogString(“Information – {0} – {1} – {2}”,

“Something has occurred!”, “Project x”, “”);


SharePoint Developer Dashboard

Rule 4: Make good use of the developer dashboard in Development and QA.

Both SharePoint 2010 and 2013 feature the ‘Developer Dashboard’ – this is a diagnostic setting that can be turned on by the farm administrator. Bear in mind however, that you’ll RARELY be able to do this in production so this is more of a tool for Development and QA. Note however, I have had to use in production when having to track down a problem with a 3rd party solution but we did it off hours.

The commands to enable the dashboard are pretty simple and can be done using the STSADM command line tool (the ‘standard’) and of course, can be done using the SharePoint Management Shell (PowerShell). The STSADM command (located in the bin folder in the SharePoint hive, i.e. c:\Program files\common files\microsoft shared\web server extensions\14 (or 15)\bin).

Enable Developer Dashboard:

stsadm –o setproperty –pn developer-dashboard –pv on

The “on” option means the Dashboard will be visible on all pages that use the default (set) master page; Or:

stsadm –o setproperty –pn developer-dashboard –pv ondemand

The “ondemand” option means the Dashboard is available via an Icon on the page (i.e. click to show it). Be aware that end-users will be able to see the icon and show the dashboard too!

Disabling the Dashboard is just as easy:

stsadm –o setproperty –pn developer-dashboard –pv off

When the dashboard is enabled in the ON, it shows virtually all of the statistics about the page load automatically (at the bottom of the page):

(SharePoint 2010 Shown)

When in the ONDEMAND mode, the page loads but the dashboard is hidden – to see it, there is an icon provided at the top of the page:

(SharePoint 2010 Shown)

The PowerShell (sorry folks, I am not a huge fan – typing is a pain!) to enable/disable the dashboard is done using the Microsoft SharePoint Management Shell. 

The Shell setup for this command is the same – the SPDeveloperDashboardLevel is all that changes:


Then one of:

$spInstance.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On;

$spInstance.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::OnDemand;

$spInstance.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::Off;

If turning On or Ondemand, add:


$spInstance.TraceEnabled = $true;

Then finish with:


So for example, to enable in the ON mode:


$spInstance.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On;


$spInstance.TraceEnabled = $true;


To turn it off:


$spInstance.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::Off;


In SharePoint 2013, there have been some changes – for one, the ONDEMAND mode is ‘depreciated’ so the modes are really just On or Off; both the STSADM and PowerShell commands are the same. When ‘On’, SP13 displays the Icon at the top of the page (like the OnDemand mode does in 2010):



When you click the Icon, a new window is presented that provides a great deal of information about the page:



As you can see, there’s a LOT more going on here! Rather than explain all of the options, view the Microsoft Video on the 2013 Developer Dashboard functionality:



Rule 5: When all else fails use Fiddler.

In a production environment, it is likely you’ll only have logs to be able to track down problems. However, the Fiddler tool is often overlooked for helping with SharePoint. A client side tool, it allows you to examine the page request and it will report any errors during the interaction. This is extremely helpful if there are images or scripts missing, etc.

Fiddler is a common HTTP analysis tool for all web sites that allows you to monitor a page and locate problems such as image errors, request errors, etc. Currently at Version 2 (Version 4 is also out but requires .NET 4.0 to be installed), this a free utility provided by Telerik (they acquired Fiddler in 2012). The download for this utility can be found here:


Fiddler can run ‘Inside’ your browser or standalone as an application but works the same either way. When inside the browser, it reports the page load – in app mode, it reports on any internet activity (regardless of browser). This will enable you to locate problems within a page, web part, etc. and can help you track down problems in CSS (missing images, etc.) – for example:



As you can see by the above, the message indicates a ‘404’ (Not Found) error on an image and indicates where it expected to find it.


Internet Explorer’s F12

Rule 6: Don’t overlook what you already have.

Finally, there is another tool many developers overlook – this is the Internet Explorer “F12 developer tools”. This tool enables you to dissect a page for HTML, CSS, Script and environment settings easily. Within IE, accessing this is done by pressing the F12 key or by selecting them from the IE Settings menu:


The tools are displayed within the browser:


This tool is INVALUABLE with SharePoint to determine styles in use since the pointer provides a quick way to find the embedded style:



Have fun and happy coding!

David Sterling – [email protected]

Sterling International Consulting Group –


Related Posts

One question

  1. Sean O'Leary says:

    Security and privacy are big issues within SharePoint. Users often are unaware of who they are sharing what with. The only way to mitigate this problem is through better training.


Ask This Expert a Question or Leave a Comment