Debugging web parts
The basic steps that we need to do in order to debug our Web Part are:
- Set the breakpoints
- Attach the ASP.Net w3wp.exe process
There are two scenarios for 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 the 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
- Check if the Web Part's project output path is set to your Local Drive's InetPubwwwrootbin folder
- Confirm that your Web Part is already present in the SafeControls list (We talked about this earlier. Check the "Register the Web Part" section.)
- Add your breakpoint as you would with any .Net application using Visual Studio.Net Okay, that was easy. We put breakpoints 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)
- In the Visual Studio.Net Debug menu, click the "Processes" option, and choose the w3wp.exe from the Debug Process dialog box. Ensure that the "Show system processes" checkbox and "Show processes in all sessions" checkbox are enabled.
- Select w3wp.exe from the "Available Processes" list and click the "Attach" Button
- 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 breakpoints. That's it. Piece'a cake. But what about remote debugging?
Interested in mastering SharePoint Training? Enroll now for a FREE demo on "SharePoint Training Course"
Debugging From A Remote Machine
Let's go again. Developers can use a remote computer to 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 the 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: InetPubwwwroot 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 FilesCommon FilesMicrosoft SharedWeb server extensions60ISAPI
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 breakpoints 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.
Tips 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 to open the 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 elements. 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 additional 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 breakpoint.
- Go to the “Debug” menu, and choose “Attach to Process”.
- Under the “Attach to:” section, click on the “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 breakpoint and will be able to step through your code.
For an in-depth understanding of SharePoint click on
- SharePoint Tutorials
- Introduction to SharePoint
- Application Pages
- SharePoint Security
- Introduction to Web Parts
- Microsoft Dynamics 365 Training In New York