take:

• 1 Late night
• 2 Cryptic, long and super complex batch files
• 480 LoC of the above
• 1 data-entry-for-tests utility that grew way to big and wacky
• 1 project on CI that either do not build, or fail all tests
• ~12 minutes is the time taking the above project to fail
• 0 lines of error output (until I figured out where to tweak the batch file)
• 2 development environments
• 1 crying baby
• 1 sleeping wife
• 5 hours
• and then finding out that some QA guys do not believe in code reuse.

The end result is:

I’m going to take care of that now.

Imagine you have something weird going on in an application.

Something is not behaving they way it should be, yet no exception is being thrown.

Then drilling down you find this piece of magic:

try
{
    DoSomething();
}
catch (Exception exception)
{
    exception.ToString();
}

Regarding my last post on the matter, Justin has commented with:

Javascript debugging has been around since VS2003.
It's not the most obvious or straight forward as in VS2008, but it's pretty easy.
The "Script explorer" window in VS2005 lets you see all the files downloaded for a certain browser process Visual Studio is currently attached to. From those files you can set a break point.
So yes, it wasn't easy, but it isn't ground breaking either.

Josh took it one step further mentioning Visual InterDev.

I consider myself a rather sophisticated user, especially when it comes to IDE of any kind.

However, I did not use Javascript Debugging in VS2005 and VS2003, for the simple reason that it was not easy enough, and did not give me enough knowledge of the runtime vars etc. while using it.

When I started .NET-ing, I've had no VisualStudio license, and no idea about SharpDevelop. So I used notepad + csc.exe + WinDbg.exe . It's workable, but it sucks. Just like JS debugging in VS.

Since javascript runs in the client, on the generated markup files, and not on the server's templates (aspx, whatever), it's not as useful as FireBug's ability to set a breakpoint on a proper client html file.

Now, quoting from ScottGu's post:

f you add/remove/update the breakpoint locations in the running HTML document, VS 2008 is also now smart enough to perform the reverse mapping and update the breakpoint in the original .aspx or .master source file on the server.  This makes it much easier to get into a nice edit/debug/edit/debug flow as you are iterating on your applications

As I said - my main reason to move to VS2008 is it's multi-target support, and js intellisense. Sure, I can get js intellisense with a lot of cool non-MS tools, but I want to have a single IDE window per solution.

The easier js debugging IS ground breaking for me, as it seams that I'll be able to use it for debugging js in IE, a thing I'm not currently doing with VS since I don't like it so much.

In a lecture I've recently gave in our company, I've discussed about the differences between Debug and Release builds, and ways to change the standard VS.NET configurations to better suit our build needs.

I'll post the important stuff here during the next few days, including some links, diagrams and other things that will make the things as clearer as can be.

Please visit here again in the next days to see the post, and comment me for any mistakes I may have, or any other suggestions in that area.

Crash all the bugs (was that your auntie?)