I'm developing on an XP (SP3) machine with VS 2010 and IIS 5.
I have two versions of the same site. We've released our first production version, so I forked the code into a new directory tree, and set up new virtual directories in IIS to point to the new trees. The projects are set up to run in the IIS rather than VS's server. The main site is an MVC 2 based project.
My problem is that, when I hit F5 in Visual Studio 2010 to begin debugging the new version, I get a "Unable to start debugging on the Web Server. The web server could not find the requested resource." I spent the better part of yesterday trying to figure out what resource it was looking for that it couldn't find. This occurs before it ever gets to "Application Start". I finally thought of looking in the Web logs, and found that whenever I hit the F5 key, the web log shows a DEBUG request for /debugattach.aspx, with a return code of 404 (not found). If I run the same sequence on the old version, it shows the same thing, but first with a 401 code, and then the request repeated with a 200 code.
My first thought was that VS must be writing out a "debugattach.aspx" file, and then invoking it, and maybe it doesn't have write permission to the directory, but, as far as I can tell, it does.
I've googled debugattach.aspx, and the first several pages of articles that are returned all seem to refer to lockup's and timeouts, mostly on IIS 7 and VS 2005. Nothing that seems to apply to this situation.
Looking at what's different between the old version that works and the new version that doesn't, the only things are the IIS setup of the virtual directories, and the web.config on the code itself. But I've gone over the two sites side by side, and can't find any differences that account for this behavior.
Does anybody have a clue they can share with me? Or can anyone point me to any documentation on what exactly debugattach.aspx is/does, and what a DEBUG HTTP request does, and/or how VS uses them?
Thanks in advance.
Based on this old posting, DebugAttach.aspx is implemented by the HTTP handler System.Web.HttpDebugHandler. I did not actually see this handler referenced anywhere in IIS7 though - it's possible that this implementation was merged into some other handler down the road. Definitely some sort of handler though. When it's working, you see 200 (success) messages in the logs.
I had this same problem 2 different ways, where F5 debugging failed in VS2010 because of a problem reaching the debug handler. Using the IIS Failed Request Tracing logs, I was able to see instances where IIS modules were interfering. In once case, UrlScan.dll was blocking the DEBUG verb. In another, a redirect from HTTP to HTTPS was causing the debug handler to return a 302. In both cases, VS barfed with a similar dialog.
At any rate, the trick here seems to be figuring out how a DEBUG request to this URL can be blocked.
In my case I had created an Empty Web Application with VS2017 on Windows 10. When I unchecked the box for ASP.NET Debugger under Project Settings -> Web the problem went away. Before that I tried almost every suggestion out there to resolve the problem.
I just ran into this as well. I had turned off the Allow unlisted file name extensions setting under Request Filtering on my local IIS server (in order to match our security hardened settings in other environments). Turns out .aspx was being blocked. I turned the setting back on and could attach with the debugger. So I turned it back off, and added an allowance at the site level for .aspx and I can attach with the debugger once again.
I'm curious as well why the debugger is looking for debugattach.aspx, and failing with this error. Especially since my app is MVC and I don't need to serve .aspx.
I had a wildcard script map for the .NET 4 version of aspnet_isapi.dll that was causing this. I was able to change the script mapping to ignore the DEBUG verb (by only using the verbs I needed for my app) and that enabled VS to attach automatically.
Having said that, I ended up using either the VS development web server or IIS Express to get my site working on an XP machine, because IIS 5.1 didn't like the combo of the wildcard script map and ASP.NET routing.
If you're running VS2010 or later, and have installed .Net 4.x or later, try renaming the "v3.0" subdirectory (e.g. "rename C:\Windows\Microsoft.Net\Framework\v3.0 v3.0.ORIGINAL"), reboot your machine, and try debugging again in Visual Studio.
This has been working like a bloody charm for me, but your mileage may vary, depending on what kind of development you're doing.
I've been running Visual Studio 2012 for two weeks like this, and I seriously cannot believe how fast things are (again!). Launching the debugger with F5 is instantaneous now, and stopping the debug session is also instantaneous. All sorts of buggy and laggy behaviours have ceased, and so far I haven't seen a single side effect.
The solution that works for me was to restart VStudio in Run As Administrator Mode.
For performance reasons we removed all the handlers from the <system.webServer> element of our MVC 5 project's web.config except for StaticFile and ExtensionlessUrlHandler-Integrated-4.0, and then started getting this error when debugging from Visual Studio.
After some investigation, we discovered that in normal use, whatever module that handles this request simply causes HTTP error 401 (unauthorized) to be returned. I was not able to find out exactly which module it was, but I was able to find the class that is responsible: System.Web.HttpDebugHandler.
Therefore, we added the following line into our web.config handlers:
<add name="DebugAttachHandler" path="DebugAttach.aspx" verb="DEBUG"
type="System.Web.HttpDebugHandler" resourceType="Unspecified" requireAccess="Script"
preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />
When that URL is hit, IIS gives out a 401 just as when all handlers are enabled, so Visual Studio is happy again.
Add <compilation debug="true"> to your Web.config.
来源：https://stackoverflow.com/questions/4471110/what-is-debugattach-aspx-and-why-cant-the-server-find-it