Visual Studio 2010 is not allowing me to debug my code_问答_开发者

So, this interesting issue has been plaguing me for the past couple of hours. Visual Studio 2010 Ultimate no longer attaches the debugger and lets me debug my code.

If I use the built in development server, then everything works fine. If I switch to Use Local IIS Web Server (http://localhost/), then all it does it attach to w3wp.exe, but no DLLs or PDBs are loaded for anything. I can go to Debug > Windows > Modules, and literally nothing is loaded in this window. Conversely, when using the built in development server, the Modules window displays all the DLLs and shows that the symbols for my DLLs have been loaded. Something is obviously amiss. The VS installation is completely bone stock.

In IIS, my website is configured with ASP.NET 2.0 (because no 3.5 exists to select from the drop down), along with read / log visits / index this resource options checked on the "Home Directory" tab.

Some of my failed ideas:

1) If I attach to process on the iexplore.exe instance where the website is displayed, it loads Internet Explorer's DLLs, but not mine.

2) I've restarted the computer multiple times

3) I've invoked devenv.exe /resetuserdata once

4) I've confirmed that every project is indeed set to开发者_运维知识库 debug and not release.

5) Deleted all \bin contents and rebuilt the solution.

6) Deleted entire solution and repulled from Source Control.

Can someone tell me what is wrong with this thing? I'm going to have an aneurism from the headache this is causing me.

You need to attach it to the IIS worker process, which OS are you using? Make sure you attach with the Managed + Native flags, in the Attach to Process. What happens if you just run (F5) your web application inside Visual Studio (that automatically attaches a debugger)? Do you get any errors?

Well there are quite a few good answers here, but I have found that the root cause of the issue for me was application pool authentication configuration. Let me lay out the scenario that I experienced and the solution and perhaps it will help someone save time....and hair.

Scenario:
I want to debug an ASP.NET web application in Visual Studio 2010 but cannot use the built-in Visual Studio web server. The reason that I could not use the built-in web server is that my application referenced assemblies built specifically for a 64-bit architecture and the VS web server would not support these. So, I had to use the option "Use Custom Web Server" in the website properties to point the debugger at a published instance of my site on a remote IIS web server.

Issue:
Even with the web.config debug options set correctly to publish debug symbols in the assembly output (i.e. compilation debug="true"), the debugger would not attach to the remote IIS process and I did not hit any breakpoints

Environment:
The Visual Studio 2010 debugger was already installed on the remote IIS web server and was running as a Windows service under the LocalSystem account.

Solution:
Enable "Anonymous Authentication" in addition to "Windows Authentication" on the web site hosted on the IIS web server.

As soon as I enabled anonymous authentication, the correct symbols were loaded by the VS remote debugger and I was able to hit the breakpoints.

Hope this helps you guys out.

Have you tried deleting the browser cache? Sometimes the browser hangs on to old code which is incompatible with the current build and thereby prevents debugging.

Does it run the app - without the debugger attached? It smells like you are attaching the debugger to a wrong process

I've had an issue before where under the build configuration screen some projects are unticked for a particular solution configuration, causing them to not build and therefore not be debuggable. Can you confirm whether or not code changes you make are actually being built and executed?

Also, what version of Windows and IIS are you running? Is it possible that your process is running under an AppPool with an account that's different to the account you're logged in with and perhaps it's a permissions problem? If it's Vista/Win7, is UAC turned on and are you running VS as administrator? I'll also second the suggestion to try a fresh project and see what that does. Are you in the debugger users local group on the machine?