Tips for Faster ASP.Net Debugging - 1/15/2011
As developers, one of the most time consuming things we do is debug our code. Some developers might actually spend more time debugging than writing code. This is not surprising. Developers are creatures of habit, we find a method that works then re-use it over and over. Changing our habits is not easy. Additionally, most of us have not dedicated much time to exploring the debugging tools to really get to know our way around them. In this blog I wanted to share a few features and techniques that maybe you either did not know or do not use that may save you considerable time. Note, most of these are not *new* techniques or features, some have been around since at least Visual Studio 2002.
Use IIS Express or IIS Instead of Cassini
By default, ASP.Net projects use a built in web server called Cassini for debugging. Cassini is the default mostly because it is very easy to use but unfortunately it has several problems with it. Instead of Cassini, I recommend using IIS Express. IIS Express was released by Microsoft as part of their WebMatrix project.
- IIS Express is MUCH faster than Cassini for loading pages
- IIS Express is MUCH more stable and reliable than Cassini. With Cassini I always had a problem where Cassini would show as running, would block the port, but the process had stopped. To resolve it I had to close all instances of Cassini then fire them back up(it IS a Microsoft product).
- IIS Express allows Remote IP listening. I can send a link to allow acceptance testers or QA testers to see my local copy across our LAN.
- Cassini does not support SSL, URL Rewriting rules and several other IIS features.
Debug vs Run Without Debugging
Only debug code when you need to debug it. If you just want to see the code run and do not need a debugger, run without debugging. On the Debug Menu choose "Start Without Debugging" or just press CTRL + F5.
- Debugging is slow to start up.
- Debugging makes your code read-only. When you stop debugging to make code changes, you lose your visual reference.
Attach/Detach to Process Instead of F5
Pressing F5 to fire up a new debugging session is a HUGE WASTE OF TIME. I almost never close my browser or leave the site I am working on. I simply attach and detach the debugger as needed. This means I do not have to re-create the problem that required debugging since I already have it on my screen. I also save the multiple steps of logging into the site and recreating the issue I already have on screen just to debug it.
- Run the site in IIS Express(not debugging)
- Compile and test in browser whenever you want
- If you find a problem, go to the Debug Menu and Choose Attach(ALT + D + P). The processes vary based upon setup, for IIS is typically w3wp.exe, for IIS Express it is iisexpress.exe.
- Once your debugging session is done and you have identified the problem, go to the Debug Menu and choose stop debugging(SHIFT + F5)
- Make whatever code changes you need. Compile and then just run the page to test. If the problem still exists and further debugging is needed, re-attach to the process(Step 3) to continue debugging
Debug Code With Quickwatch
Sometimes when debugging, we realize a function does not give us the result we expect. Rather than starting and stopping the debugger in order to work out the right code, you can often just do it right there in that debug session.
- Attach Debugger to Process via Debug Menu and Attach to Process or ALT + DP.
- Fire up the QuickWatch with Debug -> QuickWatch(ALT + DQ)
- You can enter code here to see what the output is. Ex, if you want to see what the Request.Form collection contains, you can just type in Request.Form and press enter.
Debug With Unit Tests
For those who are practicing TDD(if you aren't, you should be), writing a test can often be a nice way to debug code. The benefit of using a Unit Test for debugging is that we can call code several layers deep in our architecture with exact arguments. Ex, if I want to test a routine in my persistence layer, I can just call that routine directly with the exact arguments I want. Otherwise, you would have to either walk through a possibly lengthy UI setup to force the code down the exact path you want to test/debug or put test code your production codebase to create a shortcut to the path you want to test/debug.