Well folks, it’s been a while since I’ve added to the blog, and ironically I find myself on Christmas morning finally chasing down a little “bugger” that was causing me considerable grief yesterday afternoon. So Merry Christmas, and here are a couple of tips that may save you some time when you are trying to debug event receivers in SharePoint 2010.
The first issue that remains troublesome, even with Visual Studio 2010, is debugging the activation of your feature. For example, in my case I have a feature and it contains an event receiver. For my particular scenario I wanted to bind my event receiver to a specific list, so I had an event receiver for my feature and in the activation callout I did the binding. Of course, when there are problems in there, how do we debug that? VS 2010 just tries to push out the solution, deploy it, activate it, and activate features. Well I found the simplest way to do that is to use our new friend PowerShell. I let VS 2010 do it’s thing, and then I open up a PowerShell window. In PowerShell, I use the Enable-SPFeature cmdlet to go ahead and activate my feature. Before I execute that cmdlet, in VS 2010 I use the Tools…Attach to Process menu to select the PowerShell window I have open. Then when I execute the PowerShell command VS will hit the breakpoint in my Feature Activated event and I can step through my code. Not completely straightforward, but once you get the pattern down it proves to be quite useful.
The second issue that was really driving me crazy was debugging the event receiver itself. In SharePoint 2007 I would just attach to the w3wp.exe process for my web application and I was good to go – I’d hit my breakpoint and debug away. In SharePoint 2010 I was having no such luck. I was trying all sorts of things but could not get my debugger to step through the code. What was also strange is that the data my app would write to the event log was completely out of whack with my latest compiled version of the event receiver – it was from a build I had already changed some time ago. Two age old tricks finally gave me the clues I needed to solve this puzzle: 1) adding a System.Debugger.Break(); as the first line in my code and 2) rebooting the machine. The next time my receiver fired, the Debugger.Break() line forces one of those dialogs we’ve all seen before to appear – the one that says you’ve hit an unhandled exception, what do you want to use to debug it? When that dialog comes up, it also says which process the problem occurred. Well, it turns out that code is now running in the OWSTIMER.EXE process, no longer the w3wp.exe. Aha! I hate it when that happens. That not only explains why I couldn’t hit my break points, it also explains why the event log data my code was writing seemed dated; it was, there was an old version of my assembly in memory with owstimer.
So, I removed Debugger.Break() statement from my code, and now my process works like this:
- net stop sptimerv4
- net start sptimerv4
- Run my code and hit my breakpoint
I’m actually adding the net stop and net start commands as post-build steps to my solution, so it will all work seamlessly moving forward. Hope this helps you if you get stranded in this same scenario.