Wednesday, March 23, 2005

Visual Studio Web App Debugging

My current solution holds 32 projects. Many of the projects in my solution hold project references to other projects within the solution. The project references make XCopy deployment of our web app quick and easy. No problems here, right? Wrong! After many weeks of attempting to debug my web app, the debugger seemed to work in a very hit and miss fashion.

Here is the scenario...I have VS open. I make changed to a domain object class. I go to the Debug menu and select Run. My breakpoint are hit, and life is wonderful. Here is the catch. I stop debugging and make some more changes. I do to the Debug menu and select Start. This time, when my page opens in the browser, I get an error that the WebControls.dll can't be found. WTF?!? I stop debugging. I rebuild the solution outside of the debugger. Everything appears to be fine. I start the debugger again, only to see the same error. Okay, no need to panic. I will just close down VS and reopen (which becomes quite a lengthy chore if you are working over VPN and your solution gets the lastest version on load). That being done, I rebuild. No errors, everything looks fine. I start the debugger. By this point, about half of the time, the error is gone and things are fine. But the other half of the time, the error is STILL THERE!!! So what do I do? Occassionally I follow the theory that if I try the same thing over and over without changing anything, it is bound to work sooner or later, so I close down VS, reopen it, and give it another try. Eventually, I throw my hands up in the air and restart my machine. That always fixes the problem.

The thing is, it is difficult to meet estimate deadlines when I have to restart my machine at sporatic times throughout the day.

I am in no way suggesting that in my elevated state of frustration, it is impossible that I overlooked a simple and quick fix to my issue.

After being forcefully exposed to my rants, my co-worker, the JavaKid, finally asked me what was going on and how could he help. I told him that there was nothing he could do because the problem was that VS was the suckiest IDE in existance, end of story. Although the JavaKid loves to hear about the ways Microsoft can improve, he did ask me why I would choose to run the debugger in the way I was using it. He told me that there is a better way to debug a web app. So, to make a long story short (too late, huh?), he told me that it works much nicer with a web app if instead of selecting Debug/Start, you right click on the page you want to launch, View it in Browser (at which point I am fuming because I do NOT want to view it in browser, I want to DEBUG). Once the page is loaded in the browser, select Debug/Processes. In the list of processes, select aspnet_wp.exe, click Attach, and hit Okay. Now we are debugging! Since I have followed his advice, I have not seen that nasty error.

So the moral is: When building a web app, although the play button looks shiny and tempting, DO NOT PRESS IT! Attach to your running process instead. This tip has saved me many hours.

Also, if you tend to get the error about a resource cannot be copied because it is use by another process, try disabling your Indexing service and restarting IIS.


mike h said...

I definately agree. I've found that once a solution becomes large that launching the web app with the debugger attached just makes things very, very slow. With web apps, I tend to launch without the debugger and only attach to it when a problem comes up.

Valerie Vogt said...

I would guess that I save at least 4 hours a week now in time that I used to spend restarting everything.

Anonymous said...

Hey, just wandered in off a web search.

I was having a similar problem a few minutes ago, but I'm having better luck attaching to the w3wp.exe process after I:
1) rebuild
2) start IIS
3) Visit a page on my web site.

The problem I was having before was that the w3wp.exe process seemed to go away after I rebuilt and restarted IIS. Visiting a page on the site is what seems to cause the process to spawn.