If you're using Visual Studio 2005 and IE8 I might have an explanation: IE8 introduced a new feature called Loosely-Coupled IE (LCIE) which causes known problems when debugging VS2005 ASP.NET applications. See this thread on SO for more details and some solutions.
It turned out all my debugging problems went away when I shut down all running instances of IE8 before I started a debugging run in my ASP.NET project.
Another reason I'm posting here is to share a blog I found that lists a large number of potential solutions to the 'breakpoints not working' problem. It's nice because the blog lists in one place most of the solutions I found scattered about the Internet. Anyway the blog's author is George P. Alexander; I'll copy and paste the juicy parts here in case something happens to the article:
Using precision guided missiles: Delete the .pdb files in your obj and
bin folders. Recompile. Run.
Carpet bomb all .dlls: Delete and reload all the referenced .dlls (Like
your class projects)
Release a WMD: If #1 & #2 didn't work, delete the contents of the very
obj and bin folders itself so that
all .pdbs and .dlls are annihilated.
Reload the .dlls required and give it
a shot.
VS.Net magic: Close VS.Net and restart. Rebuild. Run. Yes, it
sometimes does work.
Windows magic: Shutdown your computer and restart. Rebuild. Run.
Execution mode: Make sure that VS.Net execution mode is set to
"Debug" and not "Release"
Web.config settings: Make sure that the XML Element "compilation" tag in
your web.config file has an attribute
with debug = "true". Only if this is
enabled will web apps and services
have their .pdb files generated with
the .dlls
Project properties #1: Make sure that Project Properties --> Debug -->
Enable "ASP.Net Debugging is true" or
"Enable the Visual Studio Hosting
Process" (depending on the version of
VS.Net you are using).
Project properties #2: Make sure that Project Properties -->
Configuration Properties --> Build -->
"Generate Debugging Information" is
set to "True".
Wrong process attached: Your debugging session may not be attached
to the right process. You may have to
step-in to manually attach the
process. This is possible with Web
Services. The option to attach a
process is within the debug menu.
Script and unmanaged code debugging: Can't debug scripts or
unmanaged code? Make sure that Project
Properties --> Debug --> "Enable ASP
Debugging" or "Enable Unmanaged
Debugging" (depending on your version
of VS.Net) is set to true.
@Page directive #1: Make sure that the AutoEventWireup attribute in your
.aspx document's @Page directive set
to "true".
@Page directive #2: Make sure that the Debug attribute in your .aspx
document's @Page directive set to
"true". If you do not find the
attribute, it's okay. By default it is
true.
Rogue .DLLs: Make sure that you do not have another instance of the .dll
running which lies else where from
your intended Project path.
14.1 Rogue .dlls sleeper cell #1: Did you install your project .dll in the
GAC folder? You could be running the
.dll hosted in your GAC folder instead
of the one in your bin folder.
Remove/Uninstall the .dll from the GAC
and then try again.
14.2 Rogue .DLLs sleeper cell #2:
C:\Documents and
Settings[UserName]\VSWebCache[Machine
Name]\:
Release a WMD (#3) on the folders that
are related to your project.
14.3 Rogue DLLs sleeper cell #3: .dlls from your project that are lying else
where but are instead referenced in
your project. You can find these out
by examining project properties. In
short, VS.Net is referring some other
.dll and not the one loaded in your
dev environment.
14.4 Rogue .DLLs sleeper cell #4: Hopefully you won't have to play with
this folder by the time you finish
with the above points...
Introducing
C:\WINDOWS\Microsoft.NET\Framework[.Net
version]\Temporary ASP.NET Files\
This folder could contain older
versions of .dlls stored in your
Windows folder which might get
referenced while running from VS.Net.
If this happens, it sucks. You can
delete as many folders and contents as
you can PERTAINING TO YOUR PROJECT.
There might be read-only locks which
you would need to disable by closing
processes. This is more of a last
ditch effort. Don't do this if you've
never played around with your Windows
folder. In most cases something done
above before this point usually does
fix it. So ideally, you don't have to
read this point by the time you're
done with the above pointers. And just
for the record, I do not recommend
anyone to explore this option or play
around with your Windows folder if you
do not have a Phd in Physics,
Mathematics, Windows and .Net.
Other tips:
- Module Window: The module window can be viewed while your application
is running from VS.Net (Debug -->
Windows --> Modules). All modules from
your project should be listed there.
If your project's .dll is listed and
the status of the Symbols is "Symbols
Loaded", you've got no problem.
If it's a message related to your .pdb
file, goto "Select Symbols" and the
appropriate .pdb file. You might have
to restart debugging or load VS.Net
again. The status should now change
to "Symbols Loaded".
2. VS.Net Options: Tool --> Options --> Debugging In VS.Net 2005 onwards, there is one more node called
"Symbols" where you can ask VS.Net to
look for symbols. This can be accessed
via the Module Window when debugging
too.