6

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

P.S. 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.

Improve this question
0

5 Answers 5

Reset to default
5

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>
Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

By changing values using QuickWatch or the Immediate Window and then moving your arrow from where it is back to the beginning or to your break point is how you retest without needing to quit and restart the debug compilation. The benefit here is fewer wait times. If there is a catastrophic problem with your code then you will still have to come out and edit it, but this will do for finding errors quickly with the fewest number of builds.
I completely agree on all points, the immediate window is especially useful and is often overlooked
The web.config change is great for when you debug a lot and make a lot of changes because then it doesn't penalize you with a slower 1st time load. You know how the 1st time you open a web site after a build it takes forever but the next time is fast? That's because the 1st time it is doing the batch. Turning batch to false means it won't have to do all that extra work. Try it and see how much time it shaves off.
5

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 e.g. <compilation ... tempDirectory="q:\temp\iistemp\"> ... </compilation>
  3. Restructure your projects
    • Selectively build the necessary projects
  4. Review a few magical settings (Most impact)
Improve this answer

Comments

3

Get an SSD and boat-loads of RAM.

Improve this answer

4 Comments

got em both, boat-loads is a little vague though :)
A minimum of 6 GB. This generally means going 64-bit, in which case you should also use 64-bit SQL Server for any database work. I've found it to be substantially faster than the 32-bit version.
That's exactly what I have. Machine is only about a year old. Everything else flies, the app I use 90% of my time on the computer though is slow(ish). Go figure.
Then there's something wrong. A one-minute load time is ridiculous on that kind of hardware. Perhaps @Fabian's link will help. I've seen massive improvements in the past by moving code and temp directories onto RAM disk, but it's usually too much effort and the code I work with these days runs fine on hardware similar to yours. Perhaps you'll have to go to such extremes.
2

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. (That is a whole other bucket of roosters, and may be the reason why you have to debug so much).

Improve this answer

4 Comments

Can you explain or provide a link? I'm all for anything more lightweight. Really I just want to see any exceptions that don't buddle up the UI.
Thanks, we are using Log4Net and I have some code in ApplicationOnError that logs them to a local rolling file. Viewing the file is a bit of a PITA though especially when the exceptions are long.
About swallowing exceptions, we do our best to avoid it but some things always manage to make their way through. The issue I am dealing with now though was tough to find because the framework (MVC in one case, NHibernate in the other) itself was swallowing the exception (and preventing it from being logged). Once we knew what was happening it was easy to fix, but until then it was a huge PITA wondering WTF was going on.
@Kyle West - if viewing the exceptions are a problem, you can change the formatting of them, and make sure to use something like UltraEdit that can better handle formatting of larger files.
0

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"...

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.