Corey Roth [MVP]

According to Google Analytics, my introduction to SharePoint topics are by far the most popular topics on the site.  I wanted to continue the trend on topics for new SharePoint developers, so I thought i would discuss debugging today.  I’ve already discussed remote debugging in the past, but I thought it would be worth spending time on simple local debugging and provide some pictures.  There may be several posts on this already, but I wanted something that I could refer to new developers I am working with.

In the ASP.NET world, you are used to working with everything on your own machine, setting a breakpoint, hitting F5 and you start debugging.  We can do it the same way with SharePoint development right?  No, of course not. 

Before we start, lets assume you built a web part and want to debug it.  If you aren’t familiar with how to build and deploy a web part, be sure and take a look at my post.  In the scenario we are talking about, you are most likely developing inside a virtual machine and it is hosted on your other computer or somewhere else.  This virtual machine has Visual Studio installed.

.PDB Files

The way you debug varies slightly by whether or not you are deploying your binary to the GAC or to the bin folder.  If you are deploying to the GAC, you do not need to worry about the .PDB file as Visual Studio will magically find it on its own when you start debugging.  However, if you are deploying to the bin folder, you must copy the .PDB file from your bin\debug folder and copy it to the bin folder in inetpub for you web application.

Start Debugging

At this point you are ready to start debugging.  First, I’ll start by marking a breakpoint in my code.

As I mentioned earlier though, you can’t just hit F5 and call it good.  Instead, you have to attach to the process running the web application your web part is on.  This is the same process used when remote debugging.  The difference is you don’t have to run the remote debugger and tell Visual Studio to connect to a remote server.  to do this, go to the Debug menu and choose Attach to Process.  You will then get a screen that looks like the one below.

The first thing you need to do is check the Show processes from all users and Show processes in all sessions checkbox.  Don’t worry about the Transport, Qualifier, or Attach to options.  The default options should work for you.  If you happened to change them in the past, use the above screenshot, to get you back to where you need to be.

Attaching to the Worker Process

What we want to do is attach to the w3wp process that is running our web application.  We know this is a w3wp.exe process, but if you look at the screenshot, you can see that we have three w3wp.exe processes in the list.  How do you know which one to use?  Well you have a number of options.  You can use brute force and try each one and hit your web page and see if the breakpoint hits.  That’s not really an ideal solution.  If you’re smart when you set up your environment, you might have created separate accounts for each application pool.  Notice above, how we have accounts named MOSS_AP_SSP, MOSS_AP_Portal, and MOSS_AP_CentralAdmin.  Obviously, I am not debugging the SSP or Central Admin, so the MOSS_AP_Portal is the account to use in my case. 

I get it though.  That is an ideal situation and you may not be lucky enough to have everything running on separate accounts, so we need an alternative solution.  Luckily, IIS has a script you can run which will tell you which worker process is running on which port.  My web application is running on port 80, so if we identify a worker process for that port, we are in luck.  In Windows Server 2003, you run cscript iisapp.vbs.  In Windows Server 2008, you run appcmd list wps.  Here is what it looks like in Windows Server 2008.

Now, I can confirm the process I want to attach to is 5980.  I’ll click on this process in the list and we can start the debugging process.  If all goes well, your breakpoint should look good in Visual Studio and it won’t have an explanation point.  If it still has an explanation point, you may just need to hit a page on the site first to get Visual Studio to load the assemblies for debugging.  Try hitting the page that has your web part and if everything works correctly, your break point should be hit and look like this.

As an ASP.NET developer, this may be different than what you are used to, but the steps involved really aren’t that bad.  The code that I debugged in this example is the same code used in the How to Build and Deploy a Web Part post.  If your breakpoint doesn’t get hit, I recommend recompiling and trying again.  Verify that you have the right worker process and copy the .PDB file out if you are deploying to the bin folder.