One important aspect when developing within SharePoint is obviously how to Debug your code.
To begin with you need to disable the friendly, or custom, error messages which has been enabled in SharePoint. You need to modify the web.config file. Here are the attributes to change…
<configuration> <SharePoint> <SafeMode CallStack="true" /> </SharePoint> <system.web> <customErrors mode="Off" /> <compilation debug="true" </system.web>
Remember to change this back when your finished debugging. Occasionally some intentional expectations are thrown to provide information back to the user. Such as ‘Can’t delete this site as it contains sub sites.’ If you don’t put custom errors back on the user will get an un-friendly stack trace instead.
If, in your development environment you are running SharePoint locally, on the same machine that visual studio has been installed then debugging is fairly easy…
Lets say you have just installed a Feature which has some feature activation code and you wont to step through your code when the feature is activated, before deploying the feature just add a break point at the start of your activation method.
Once you have deployed the feature you will have either deployed the supporting DLL to the GAC (Global Assembly Cache) or in the SharePoints’ site corresponding BIN directory. If you have the Visual Studio solution running then you wont need to copy any PCB supporting debug files. Just attach to the IIS worker process from Visual Studio and your break point will fire when you activate the feature.
If you need to debug your code from a remote server you need to install the Visual Studio remote debugger on the server. Its a little tricky as you need to get your local firewall configured to let you through, which had me stumped for some time. If its just for a quick debug you could disable your firewall, may save you some headaches, but remember to put it back on again. Check the documentation for setting this up on msdn http://msdn.microsoft.com/en-us/library/bt727f1t.aspx