Every SharePoint developper is quickly in front of web parts development or workflows. Unfortunately, when things are wrong, only a few of them know how to debug, analyse and correct the code without problems. All developers had to do this and know that less it last, greater it is.
So, here is a little how-to article about event handlers debugging.
I will not write more about event handlers usage or deployment. If you want to have information about event handler, follow the link: MSDN. The most important part for us is that event handlers are deployed to SharePoint bin folder or Global Assembly Cache (GAC). Furthermore, assemblies containing event handlers are loaded dynamically when needed.
Event handlers management tools
Some management tools are available all across the Internet. Most part of them are free of charge. From my personal point of view, there is two ones which should be used : SP RAD Studio, which will be available next month and Event handler Explorer. You can do it from the following site: Event Handler Explorer.
Why should we use this kind of tool? The objective is to check that event handler is attached to document librairy or list we want.
Event Handler Explorer is easy to use but here is a quick overview of the tool:
When program is loaded, all controls are blank. You have to indicate what is the site collection url.
As soon as you did it, you can navigate through the complete site collection and select the list or the document library you want.
After this, click on Event Handlers. If there is some attached event handlers, they will be listed beside this node.
By selecting an event handler, you can get more information about it on the right panel.
It is also possible to attach or detach event handlers through this interface.
SharePoint logs usage
Errors that are not handled in an event handler is logged in the SharePoint file log. All the files (by defaut, there is one every 30 minutes) are located in the folder c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS if you let default parameters during installation.
Search in the files for the class name, Company.SharePoint.EventHandlers.EventHandlerName for example so you will be able to see if there was an error or not. This kind of error will look like:
02/25/2009 21:14:39.61 w3wp.exe (0x0C04) 0x04DC Windows SharePoint Services General 8e0c Critical Event manager error: Could not load file or assembly 'Company.SharePoint.EventHandlers.EventHandlerName , Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5' or one of its dependencies. The system cannot find the file specified.
If you are using Microsoft Office SharePoint Server 2007, you can directly write information in these logs. You have to add a reference to Microsoft.Office.Server.dll DLL located in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI\ folder. Then, in your code, add the following instruction: Microsoft.Office.Server.Diagnostics.PortalLog.LogString(“your text”);
Visual Studio debugging
Some processes are required to run SharePoint. One of them is used to manage and render web pages in the browser. In fact, this process is used by all ASP.NET applications and SharePoint is based on ASP.NET. So if we want to see what happens in our code, we have to attach the debugger to w3wp.exe process.To attach the debugger, go to Visual Studio and select Attach to a process… in the Debug menu.
Maybe you will find more than one w3wp process. If true, you can attach the debugger to all the instances of the process.
Select all the w3wp instance by holding CTRL during selection.
If you haven’t any w3wp process, go to your browser and open a SharePoint url so the w3wp will start to run. Then click on Refresh button and select the newly process.
Now you have your debugger attached to your event handler. You just have to add some breakpoints and run debugger step by step. There is a lot of features provided by Visual Studio, do not hesitate to use them (Debugging in Visual Studio)!