How to Guide: Debug SharePoint 2007 Event Handler Feature Receivers

Have you wondered how to debug in .NET the event handler you deployed in a list? It could be tricky at first but debugging event handlers is no different from debugging ASP.Net codes.

How to debug Event Handler Features?

These are the steps you need to debug your assembly when they are deployed in GAC. The steps are the same when your assembly is deployed in the site bin directory, however you would need to provide the necessary CAS policy for it to work.

Anyways, here you go:

1. Compile your event handler in debug mode.
2. Open GAC or type "C:\Windows\Assembly" in the run command.
3. Register your event handler feature using stsadm -o installfeature -filename [featurelocation]\feature.xml (Please note, that featues and feature deployment is not covered in this post. We would talk more about features next time around.)
4. Open explorer and find your assembly. The default location is in your bin folder of the project folder.
5. Drag and drop the assembly to the GAC folder.
6. Map your GAC folder so that it would not open in under a shell framework. I use this simple and old trick in dos mode. Open you command windows then type subst g: c:\windows\assembly.

The g parameter is the drive you want to map the GAC folder. If you encounter and error when mapping the GAC folder it is possible that the drive you specified is already in use. Choose an available drive.

7. Locate the folder "GAC_MSIL" in the mapped drive.
8. Locate the folder of the assembly you have copied in step 4. The name of the folder is the same as your assembly name. Sometime you would find subfolders inside the assembly folder name, this happens when your build version settings of the assembly is set to increment. If your assembly is compiled in fixed version then you would see just one sub-folder.
9. Copy your assemblies' .pdb file. This is the same location as was described in step 3.
10. Do and IISReset. It is not required but I would almost always do an IISReset to ensure everything goes well.
11. Go to Visual Studio and attach the debugger to your process -- w3wp.exe. Since you performed an IISReset, the latest one goes up upon request.
12. Your event handler should now stop in the breakpoints you set when you trigger them.

As mentioned, we would discuss features, creation of features and deployment in the succeeding articles.

1. Dvolution | Debugging SharePoint Events, September 12, 2008 at 7:07 am

   [...] from. I tried a heck of a lot of debug methods but none made me any wiser. Then I bumped into this article which describes how you can single-step through event handler code. This is how you pull it [...]

2. Sowmya, October 4, 2008 at 11:42 am

   Hey Thanks a lot…That helped me.
   Thanks once again

3. Jack, October 10, 2008 at 5:26 am

   Thanks, great article. Very helpful.
   Few comments:

   “9. Copy your assemblies’ .pdb file” – it is not clear where to copy pdb file. And for me it didn’t make a difference – meaning I can debug even I didn’t copy pdb at all.

   “9. Copy your assemblies’ .pdb file. This is the same location as was described in step 3.” – location was described in step 4, not 3.

   apart from that I was facing the issue “The breakpoint will not currently be hit. No symbols have been loaded for this document” but it seems to be stopping at the breakpoint which is confusing. Anyway, it works. Great stuff!

4. Dvolution » Debugging SharePoint Events, February 17, 2010 at 2:07 am

   [...] from. I tried a heck of a lot of debug methods but none made me any wiser. Then I bumped into this article which describes how you can single-step through event handler [...]

Leave a Comment