Debugging code is as important as writing the code. There are few differences in debugging SharePoint code as compared to traditional ASP.NET applications. In ASP.NET you can just set the breakpoint in the code. Press F5 and you can debug the code line by line. It is not as simple in SharePoint because you already have a web application up and running to which you are deploying your customization.
Following are the various techniques to debug code in SharePoint.
1.Debugging in Visual Studio
- Compile your solution and deploy it (Don't press F5).
- Select Tools –> Options from Visual Studio and uncheck “Enable Just My Code (Managed only)" check box.(Some server may work without doing this step so let see how it goes).
- Select Tools –> Attach to Process from Visual Studio and select w3wp.exe worker process you want your debugger to be attached to.
- You can do the same above step "Attach to Process" under debug menu also.
- Sometimes the breakpoints do not load even after attaching the debugger. To solve this problem click the Select button in the Attach to Process screen and select only the Managed (v2.0,v1.1,v1.0) option.
- Pick the right w3wp.exe to attach among Multiple Worker processes as in the above image while debugging.
- Now go to command prompt, go to the directory "C:\windows\System32\Inetsrv"
- Enter "Appcmd list wp"
- Now in the .cs file, add a break-point at the any of the method or line and hit F5.
- Browse to the site where you deployed the web part and the debugger stops code execution at the break point.So after this step it is like debugging usual ASP.NET applications.
- Happy Debugging!.
- Note: Debugging a sandboxed solution in Visual Studio is similar but requires you to attach to the SPUCWorkerProcess.exe
Custom errors are the way to hide the yellow error screen and show more user friendly messages. Unfortunately they don’t help much in understanding the root cause of issues, and we normally turn these off during the development phase. In SharePoint you normally see a screen showing unexpected error or limited error detail. To see it for yourself go to the farm solution project created earlier in this hour and add throw new Exception(); in the CreateChildControls method. Build and redeploy the solution and refresh the page where the web part is hosted. You see the custom error screen like the image below.
To disable custom errors, open the web.config file for you web application. You can usually find it at C:\Inetpub\wwwroot\wss\VirtualDirectories in a folder that corresponds to the port number of your web application. Search for the customErrors tag and set the mode attribute to Off or RemoteOnly. Then find the SafeMode tag and set the CallStack and AllowPageLevelTrace attributes to true. Refresh the page and you see more detailed error information as the below image,
3.Introducing Developer Dashboard
SharePoint 2010 comes with a developer dashboard that you will find useful in debugging especially in a production environment. The developer dashboard provides a lot of information such as the stack trace of the current execution and also the SQL queries currently executing. To enable the developer dashboard execute the following command through poweshell:
stsadm -o setproperty -pn developer-dashboard -pv OnDemand
The other options for this are On and Off in place of OnDemand. After executing this command, refresh your site and you can see a new icon on the top left after the username. Click it and you can see the developer dashboard at the bottom of the same page, as shown below. Note that you need to remove the throw new Exception(); statement that we added in the previous section and redeploy the solution, or else the page will continue to show the error screen.
Wow I like this article a lot and it easy to understand
ReplyDeletesharepoint administrator training
Awesome article about debugging sharepoint solutions. Thanks for sharing..Keep posting more articles.
ReplyDeletesharepoint solution providers