up vote 1 down vote favorite
share [g+] share [fb]

I have no idea why, but the debugger for a specific project has spontaneously stopped working. I say spontaneously because it worked one day, I went home for the weekend, came back, and suddenly it didn't work.

When I build the solution, the local web server starts up and the site loads in a browser like it's supposed to. However, the debugger is no longer running - I have to manually "Attach to process" with the development server if I want to test breakpoints or step through code.

The strange thing is: I'm not having this problem with any other project on my system.

Is there a setting I might have tripped that caused this? What can I do to fix the problem so I can skip the manual "Attach to process" step every time I build?

link|improve this question
100% accept rate
feedback

3 Answers

up vote 1 down vote

This article might explain why : Unable to debug Web Site with Top Level Location

An error in the web.config can cause the debugger to attach and then error-out immediately without any sort of warning or error. You should very carefully verify web.config, as the error might not be the same as in the article.

link|improve this answer
This doesn't really help ... since I'm not the only developer on the project, and it's working fine with everyone else. I'm using the same SVN checkout, but while they have an automatically attached debugger I don't ... and since we're on the same SVN revision, we have the same web.config file. – EAMann Aug 6 '10 at 19:38
@EAMann: Isn't it still possible that something in the web.config file doesn't work for your computer? You might also delete and reget the entire SVN revision, just in case there is some difference after all on your computer. – harrymc Aug 6 '10 at 20:13
See my update on the accepted answer. It turned out to be a strange line in web.config that invoked a .NET 4 setting in my .NET 3.5 solution ... – EAMann Oct 5 '10 at 15:12
Thanks, happy to hear I was right about web.config, although I couldn't foresee the actual error. Just a remark: Normally the poster should limit himself to editing his post, as it's somewhat bizarre to answer one's own question. – harrymc Oct 5 '10 at 15:30
feedback
up vote 0 down vote

If it's a web site*, right-click project file -> click Property Pages -> click Start Options

If it's a web application*, right-click project file -> click Properties -> click Web

Down the bottom is a section called Debuggers. Make sure ASP .NET is ticked. If not then it could explain the behaviour you are experiencing.

*In .NET there are two main types of project file for web sites.

link|improve this answer
It is a web site, and I just verified that ASP.NET is ticked on the Debuggers section of Property Pages >> Start Options ... so, no, that's not the issue. – EAMann Aug 6 '10 at 19:37
feedback
up vote 0 down vote accepted

I still haven't been able to determine what caused the original problem, but there's a short-term fix available for anyone also facing this issue.

After you build your project (by selecting Bulid » Build Solution or just clicking Start Debugging), you can attach the debugger to your instance of the ASP.NET Development Server.

Go to Debug » Attach to Process and scroll down until you see the process WebDev.WebServer.EXE. It will be labelled: ASP.NET Development Server - Port XXXX. It's usually the last or very near the last item in the list.

Select this process and click Attach. You'll then have all the usual debugging tools available and can step through code after throwing exceptions or hitting breakpoints.

This isn't a permanent fix! You'll have to go back through the same process every time you build or re-build your project. A pain, yes, but still a useful workaround.

Update - 10/5/10

I received an email yesterday from someone who was suffering from the same problem. We determined that it was an issue in web.config that seems to have been added by VS. In both cases, significant portions of the web.config file was enclosed in a <location> block with the inheritInChildApplications property set to "false."

Apparently, this is a setting used in .NET 4, but which is illegal in .NET 3.5 ... since VS 2008 can't build to .NET 4 in the first place, how these lines were added is a mystery.

Removing the <location path="." inheritInChildApplications="false"> and </location> tags resulted in a working web.config file, a complete build of the website, and an attached debugger. Finally, a full, permanent solution!

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.