One of the things that I've come to both love and loathe are SharePoint Feature Receivers. They allow a developer to perform custom actions when a feature is installed, activated, deactivated, or uninstalled.
Feature Receivers are great in principle, but have a tendency--if you ask me--to be difficult to write correctly. Furthermore, debugging them is difficult, or at best, unwieldy. Unfortunately, this is one of those places where you really want to be able to debug your code.
So how do you do it?
As it turns out, it's very easy.
This is actually a simply two-step process. This works with SharePoint 2007 and SharePoint 2010. I have only tested this in Visual Studio 2010, but in principle it should work in 2008 as well.
Step One - Tweaking Debugger Settings
The first step, of two, is simply tweaking some debugger settings in Visual Studio. With Studio open, click
Tools > Options > Debugging (in the left pane) > UNCHECK Enable Just My Code (Managed only).
This, in essence, instructs Studio to do its best to figure out where to get source code from during debugging sessions.
Step Two - The Secret Sauce - Manually Launch Debugger
The other trick to debugging feature receivers is, unsurprisingly, extremely simple once one thinks about it. The typical way to debug a SharePoint site is to use the Attach to Process debugger command, and attach to w3wp.exe. Similar things can be done for feature receivers, but why not make things a bit easier on yourself?
Using this one line of code, you can force Windows to ask you if you'd like to start a debugging session:
The result, when you run your feature receiver, looks like this:
At this juncture, if I click Yes, Windows will attach my already-running Studio session to the Feature Receiver, allowing me to debug, and to do so easily.
Whenever I'm done working out the kinks with my code, I can either do a release build (thanks to my preprocessor conditional), or I can simply remove the Launch() call.
Problem solved!
ICF Ironworks is always on the lookout for experienced professionals who believe in hard work, having fun, and great client service.
Thats a good tip.. Thanks for the post Casey..
Posted by: Chaitu | 03/27/2011 at 07:38 PM
Thanks, man! You saved my day. I always used the same old techinique of attaching the debugger to the process. Recently, I tried the exactly same technique and somehow it didn't work. I almost spent a half day to figure out why I can't debug and found your article.
Posted by: sp2007 | 03/10/2012 at 07:46 PM