如何在Visual Studio 2010中更快地调试ASP.NET应用程序

Question

I am getting pretty frustrated by debugging, but maybe I am just doing it wrong.

When I am actively developing it is extremely cumbersome to write some code, fire up the debugger to test said code, wait a minute for the debugger to start, look at the page in the browser, stop the debugger, edit the code, rinse, lather, repeat.

I can get around that by using CTRL-F5 and CTRL-SHIFT-B during development but I lose all the benefits of the debugger.

Is there a better way to use the debugger, or something else I can do to get quick rebuilds and use of the debugger?

Thanks,

Kyle

PS I/we do write unit tests, but you also need to test your app in the browser so please no "you shouldn't have this problem if your unit tests were written properly." comments ;)

Update

Thanks for the "get a better machine" suggestions. Not much I can do there. Loads of RAM and an Intel SSD. I shouldn't need more than a $2500 machine to code a web app.

Answer 1

You should take a look at this post (tweeted by Scott Guthrie):

Slash your ASP.NET compile/load time without any hard work http://blog.lavablast.com/post/2010/12/01/Slash-your-ASPNET-compileload-time.aspx

Summary

1. Get better hardware (Big impact)
2. Store your temporary IIS files on your fastest disk or a RAM disk eg <compilation ... tempDirectory="q:\\temp\\iistemp\\"> ... </compilation>
3. Restructure your projects
   • Selectively build the necessary projects
4. Review a few magical settings (Most impact)
   • <compilation ... batch="false"> ...</compilation>
   • <compilation ... optimizeCompilations="true"> ... </compilation>

Answer 2

Debug fewer times: If you are stopping the debugger to change values or test different scenarios then don't. While debugging you can change the values of the variables using QuickWatch or the Immediate Window .

Make debugging less costly: Turning off batch will make your page load faster on the first time since it will no longer precompile all of your pages and user controls. This is good for development if you are making changes quite often.

<compilation ... batch="false"> ...</compilation>

Answer 3

获取SSD和大量的RAM。

Answer 4

Maybe what you need is not to debug faster, but to reduce the amount of times you need to debug. Perhaps a more liberal Debug.* or trace logging approach would help.

@Kyle West - Well... there are a bunch of different ways you can go about it. The approach that works best for me is to use the MS Enterprise Library Logging app block ( main site ) to log events to a rolling daily file. The log level can be ratcheted up (verbose detail) or down (exceptions only), just by editing the .config file.

There is a lot in the app block, so we created a wrapper around the logging calls so that we can more easily make the calls that matter. For example,

DebugEvent.Log(String.Format("the value of _myVariable is {0}", _myVariable))
InfoEvent.Log("Reached the entry to the gatesOfHell method")
ExceptionEvent.Log(ex)

The nice thing about EL is you can change the config without having to change code. So if you want to log to the event log or even email, its just a few lines of configuration.

You can also substitute any other logger (log4Net, etc), or use the built in Debug or Trace in a way that is useful for you.

The statement "Really I just want to see any exceptions that don't buddle up the UI." is a bit worrisome, and implies that exception swallowing or some similar poor practice is happening. (Thats a whole other bucket of roosters , and may be the reason why you have to debug so much).

Answer 5

Well, there are tools like Watin , which allow you to script browser interaction, but I don't think that's really what you want.

I guess the answer here is "Get a faster machine"...