17 October, 2020
The basic steps that we need to do in order to debug our Web Part are:
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.
Step 1: Set the breakpoints
I assume your Web Part project is already open via Visual Studio.Net
Step 2: Attaching the ASP.Net worker process (w3wp.exe)
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"
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:
For an in-depth understanding of SharePoint click on
TekSlate is the best online training provider in delivering world-class IT skills to individuals and corporates from all parts of the globe. We are proven experts in accumulating every need of an IT skills upgrade aspirant and have delivered excellent services. We aim to bring you all the essentials to learn and master new technologies in the market with our articles, blogs, and videos. Build your career success with us, enhancing most in-demand skills .