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)
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