NOTE: This applies to going through the steps manually using Visual Studio 2010. And the issue in concern, is breakpoints not being hit.
Debugging web parts in SharePoint are not difficult, but they can be annoying. This article on MSDN, (albeit an old one) describes how this can be achieved.
Essentially, ensure that the web part assembly is part of your web.config safe control list. Then, from Visual Studio, select Debug –> Attach to Process. This is where you will need to select the application pool IIS Process, which will be w3wp.exe.
Now you can set your breakpoint and begin debugging….right? Well not exactly, chances are you will run into a problem in which, the breakpoint will currently not be hit.
This is because we are trusting Visual Studio 2010 to determine the type of code being debugged. We’ll have to change this, by selecting Debug –> Attach to Process, then under Attach To, click Select.
Note the option, Automatically determine the type of code to debug
Click and Select Debug these code types option. The tick and select Managed (v2.0, v1.1, v1.0), click on OK, then attach the w3wp.exe process.
Now set you breakpoint and begin debugging your web part. The issue of not hitting a breakpoint will not occur again.