Nik Codes

Last time I covered how to show full debugging information in WSS by editing the web.config.  That’s a great tip to easily peer into WSS, but it’s no step debugging.

To get step debugging there are a few simple things that you need to do.

1. Attach to the proper process:

Depending on what you are trying to debug - you need to attach Visual Studio to the proper process.  For WSS development, most of the time you will want to attach to w3wp.exe.  Its the IIS worker process and will allow you to debug web parts, feature receivers, etc.

Attaching to w3wp.exe is easy in Visual Studio: Select Debug > Attach to Process find w3wp.exe in the list and press Attach.

You may notice more than one instance of w3wp.exe running - which is normal since each IIS Application Pool runs in its own worker process.  To figure out which process you need to attach to you can run iisapp from the command line.

The first time you run iisapp you will see an alert box that says “This script does not work with WScript.“:

Just press OK and then Yes to the next prompt.

This will give you the success message “Successfully registered CScript” at which point you are good to run iisapp.

To be sure you connected to the proper process you can press  Ctrl + D, M to bring up the Modules window.  This is a list of all assemblies that Visual Studio is monitoring.  Make sure the assembly you want to debug is in this list.

Side Note:
To debug SPJobDefinition’s as they run, you must attach to the owstimer.exe process.

To make all this attaching even easier, Andrew Connell has a nice little macro that will automatically attach to these processes for you.

2. Load Symbols

Visual Studio needs access to .PDB files to give you the best debugging experience.  The problem is that most of the time when you are working with WSS you have your assembly loaded in the GAC and aren’t too sure where the .PDB file is, or where it should go.

The best way around this problem is to use a symbol server.

A symbol server is nothing more than a folder on your machine that has all the .PDB files you need in it.  I recommend that you make a shared folder on your build server specifically for this purpose - so that when you do a build, you can easily automate putting PDB’s in their proper place.

Once you have created a folder where you plan to store your PDB files you need to populate it using a program named symstore.exe which comes with the Debugging tools for Windows.

Once you have installed the tools simply run:

symstore add /f “Path/To/*.PDB” /r /s “Path/To/Shared/Folder” /t “Product Name“

and your .PDB’s are now on the Symbol Server!

Note:
I’ve added the path to symstore.exe to my PATH environment variable.

I’ve added that command to my post-build script in Visual Studio so that the newest version of the .PDB’s are always available to me as I debug.  (Although it’s probably better to have your build server do this part.)

To make it a little simpler to manage your symbol server be sure to check out PowerShell Symbol Store - a nice GUI for managing symbol servers plus PowerShell scripts to help you along.

Finally once you have your Symbol Server setup you have to tell Visual Studio where it is.  Select Tools > Options > Debugging > Symbols and add the path.

Now attach to the proper process, browse around your SharePoint site and anytime you execute code with a breakpoint on it Visual Studio will begin to flash and you will be debugging!

This is a rehash of info that’s already all over the web - but for me to find quickly I’ll repeat:

To enable debugging in WSS 3.0 update C:\Inetpub\wwwroot\wss\VirtualDirectories\80\web.config so that these attributes are set as seen below.

<configuration>
	<SharePoint>
		<SafeMode CallStack="true">
	</SharePoint>
	<system.web>
		<customErrors mode="Off" />
		<compilation batch="true" debug="true">
	</system.web>
</configuration>

DO NOT REPLACE YOUR WEB.CONFIG WITH THE ABOVE FILE.  Simply change the attributes in your file to match the ones listed above.