Debugging on SharePoint is much the same as debugging any other ASP.Net application…you can use the same techniques. Here are some of my tips for diagnosing & solving your problems…
Debugging starts with your first line of code
As you start writing some code you need to bear in mind that at some point you will need to debug it. This may mean attaching a debugger (easy) or looking at a crash dump (hard). This means debugging should always be at the back of your mind when writing any code…ask yourself “when this is live how am I going to find out what has gone wrong?”
In practice this means making full use of the features of .Net … System.Diagnostics, try…catch, exception logging, etc. One thing in particular to remember is that if you do ever have to look at a crash dump your variable & method names will be in there too. The more descriptive they are the easier it is going to be to analyse the dump. Also bear in mind that the less code in each method the easier it will be to pin-point the location of the error. Les Smith has some good points to make about refactoring…I would add that refactoring making debugging easier!
Use Trace.Write & Debug.Write
This is the first thing I would recommend. Adding these method calls at suitable places in your code can really help to solve problems. Used in conjunction with DebugView these methods can give you great insight to what is happening within your code. Personally I use Trace whenever something unexpected or ‘out of the ordinary’ occurs, normally exceptions, but it could be anything that may help solve a problem. Calls to the Trace methods remain in release code and so will add an overhead to the code execution. I generally use Debug to enable me to see code execution paths during development and as these do nothing in a release build can be used much more liberally.
Using the Trace statements can really help when you cannot attach a debugger (on a live server) to give you more information of what has gone wrong. If you ensure you use try…catch…finally blocks throughout your code, using Trace to log the exception makes it easy to see where the error has occurred (including the call stack) simply by running DebugView on the server.
When developing ASP.Net controls and WebParts I like to add try…catch blocks when overriding methods likeOnInit, OnLoad, CreateChildControls and Render. I do this because I don’t what the whole page to fail to render simply because one control has a problem…If the search box control throws an exception, why shouldn’t the rest of the page display? Therefore my Render method would look like this…
protected override void Render(HtmlTextWriter writer)
// Do something to render the control, which may cause an exception
catch (Exception ex)
// Maybe render an error message
This way if an exception is thrown the page will still render…the user may not get the full functionality of the page, but at least they get something. Essentially wrapping your code in a try…catch block has a negligible hit in terms of performance and so you should look to using them wherever something may throw, even if you just Trace and re-throw the exception. Also you should bear in mind that throwing an exception is a big overhead and should only be used when a real exception has occurred…something you really did not expect and cannot recover from.
Check the SharePoint log files
These will be located in the /12/LOGS folder. The log files contain errors & messages generated by SharePoint. I have to say that generally they don’t give you as much information as you would like (sometimes nothing), but occasionally they point you straight to the problem. Either way you should always check them just in case.
You should also know that you can increase or decrease the amount of logging SharePoint does in Central Administration. Here you can change the verbosity of the logging within different parts of the application. Its not the easiest interface to use, but you can increase the number of messages logged…doing this has solved problems for me in the past.
You change the settings under ‘Logging and Reporting’ in the operations tab…