The basic steps that we need to do in order debug our Web Part are:
1. Set the break points
2. Attach the ASP.Net w3wp.exe process
There are two scenarios to debugging your Web Part. The first scenario would have you debug them on your local machine while the second scenario would have you develop your SharePoint Web Part on your local machine but host and debug the Web Part on a remote machine where SharePoint exists.
Debugging On Your Local Machine
Step 1: Set the breakpoints
I assume your Web Part project is already open via Visual Studio.Net
1. Check if the Web Part’s project output path is set to your Local Drive’s \InetPub\wwwroot\bin folder
2. Confirm that your Web Part is already present in the SafeControls list (We talked about this earlier. Check the “Register the Web Part” section.)
3. Add your break point as you would with any .Net application using Visual Studio.Net
Okay, that was easy. We put break points all over our Web Part to debug whatever we want. The next task would require us to Attach the ASP.Net worker Process.
Step 2: Attaching the ASP.Net worker process (w3wp.exe)
1. In the Visual Studio.Net Debug menu, click the “Processes” option and choose the w3wp.exe from the Debug Process dialog box. Ensure that “Show system processes” checkbox and “Show processes in all sessions” checkbox are enabled.
2. Select w3wp.exe from the “Available Processes” list and click the “Attach” Button
3. A dialog box will pop up listing program types that you wish to debug. Choose “Common Language Runtime” and click the OK button and close the dialog box.
Great! That’s it. Now you’re all ready to go and debug unleashed! Now we’re reached the stage where debugging your SharePoint Web Part is similar to debugging any ASP.Net web application.
Step 3: Finally, Debugging!
Open the SharePoint site and navigate to the page that contains your Web Part. Once this page starts rendering, the control will switch over to your program in Visual Studio.Net wherever you have placed your break points.
That’s it. Piece’a cake.
But what about remote debugging?
Debugging From A Remote Machine
Let’s go again.
Developers can use a remote computer develop and debug SharePoint Web Parts also. We have a server (remote machine) and a client machine. I assume your Web part project is open in Visual Studio.Net on the client machine and waiting for us to play around.
1. Ensure that remote server has been installed with remote debugging services configured correctly. Verify that you have given shared access to the virtual directory containing the SharePoint application (LocalDrive:\InetPub\wwwroot\ whatever) with read write permissions.
2. Share and give read access to the folder that contains Microsoft.SharePoint.dll. This would usually be in the Program Files\Common Files\Microsoft Shared\Web server extensions\60\ISAPI
3. Make sure that the SharePoint Web Part is included in the SafeControls list on the remote server also.
4. Ensure that the project’s output path is set to the folder that contains the dll file on the remote machine.
5. Add your break points and attach the ASP.Net worker process by navigating yourself to the remote server. Attaching the ASP.Net worker process follows the same steps we discussed earlier in “Attaching the ASP.Net worker process (w3wp.exe)”
Neat. Now load your remote SharePoint site and navigate yourself to the page that contains your Web Part. The control should pass over to Visual Studio.Net breakpoints spread across your Web Part project while rendering. Give it another shot should get you used to it like the back of your hand.
Interested in mastering SharePoint Training? Enroll now for FREE demo on SharePoint Training Course.
1. A Common Error: There’s a good chance that you could get an error message “Unable to replace” after compiling the Web Part. This tends to happen when the ASP.Net worker process w3wp.exe locks an older copy of the assembly from the bin folder. In case you come across this error, remember open task manager and terminate the w3wp.exe process. Once terminated, you can recompile your Web Part Project and use the assembly.
2. The CallStack Attribute: All of us, as developers hate it when our programs give error messages that are not descriptive and therefore, totally unhelpful. Well guess what, by default SharePoint tells you that you got an error but by default, it does not tell you any specific reason as to why an error occurred in the first place. Actually, SharePoint displays only a restricted set of exceptions on the client machine due to security reasons.
Fortunately for us developers, there’s a way to overcome this security restriction. SharePoint disables the CallStack attribute present in the web.config file which is responsible for allowing the client to display exceptions with stack information in the standard ASP.Net error format.
Here’s how you get it done right:
In your web.config file, look for element. Within this element, look for
At this point, set the CallStack Attribute to true :
Further, check that the customErrors element is disabled
Now you’ll get the required exception details that you normally would with any ASP.Net web application.
We can further use ASP.Net tracing mechanisms to provide us with addition information on our Web Part. Once again, this feature is not available to use by default and therefore, we would have to open up our Web Part’s web.config file and search for the element and add one more new child element within this element:
< trace enabled =”true” pageOutput = “true”/>
Neat. Now we’ve got all the right techniques to get our Web Parts debugged right with the help of a .Net development environment, ASP.Net and SharePoint.
So hope you guys have a great time with SharePoint. Anything interesting? buzz me!
Happy Programming Y’all!
Most of you probably already have figured this out, but for those of you who still have not, here is how you can debug your web part in Visual Studio 2010:
- Deploy your Web Part
- Add the Web Part to Page
- In your code, create a break point.
- Go to “Debug” menu, and choose “Attach to Process”.
- Under “Attach to:” section, click on “Select …” button.
- Uncheck all options, checking ONLY “Managed (v2.0, v1.1, v1.0) code”.
- Check the “Show processes in all sessions” checkbox.
- Select all “w3wp.exe” Processes, then click on the “Attach” button.
- Run your page that contains the Web Part. You should now hit your break point, and will be able to step through your code.
For Indepth understanding of SharePoint click on