VS.NET JavaScript debugging

I use this when I'm testing between the javascript and my c# request handler.

but for straight javascript debugging, the firefox FireBug add-in is easier and faster.

It's pretty decent, but ise it for a while, and you start running into it's frustrating limitations - especially around setting breakpoints.

Thanks for the FireBug tip, John - I've used the DOM inspector and a javascript eval plugin, but hadn't seen that one yet. Looks nice!

I like the JS debugging too, and have found the only reliable way to 'set a breakpoint' is to use the 'debugger' javascript command. E.g.:

function someFunct()
{
debugger;
// some code.
}

Interesting news indeed, but I think I will stick with FireBug. Besides the full blown JavaScript debugger, this extension contains a very nice interface to explore the DOM tree of a page, even though the code is a mess :)

It may be obvious but worth noting that this only works with IE. My default browser is Firefox, for a moment I was confused about why it wasn't working.

You can also do this by attaching to the IE process from within Visual Studio, and viewing the 'running documents' window.

Pick the document with the javascript in it, and set breakpoints from within VS.

Hi Fritz, I wrote a post about tips and tools for ASP.NET debugging a while ago. http://dotnetslackers.com/community/blogs/simoneb/archive/2006/07/24/216.aspx

Nice list Simone - thanks!

I just read this on Fritz Onion's blog, he has instructions on how to configure IE and your code to make...

I use a similar technique and it is not just related to ASP.NET. It also realted to any client-side programming language available.

Of course clear the debug flag in IE as you mentioned earlier. Purposelfully inject a bug where you want to begin debugging. For example using javascript:

function foo(){
var a = 1;
fffffffffffffffff
var b = 2;
}

The bug, "fffffffffffffffff" will raise an exception, cause the debugger to run, and allow you to choose which debugger to use. Do not use numbers or function names.

I seam to remember debugging client side JavaScript both in VS2003 and event in Visual InterDev (Visual Studio 6).

All the above menthoned techniques for setting breakpoints worked there too. I actually forgot about using the 'running documents' window to set breakpoints. This was the method that worked best (for me) in Visual InterDev.

A couple more points:

1. When debugging is enabled in IE you have the menu option View->Script Debugger->Break at Next Statement. I find this a very usefull way to break into debug at the right time.

2. When using an AJAX framework like Atlas, it builds its DOM extensions on the window object. If I use a class MyNamespace.MyClass with method DoService I can examine what the framework built on the DOM by querying the DOM in the Immediate window like so:
?window.MyNamespace
shows the subnamespaces that were created and the classes.
?window.MyNamespace.MyClass
shows the methods.
?window.MyNamesapce.MyClass.DoService.toString()
Shows the code generated for the method.

What I am really hurting for is a decent intellisence support for client side Javascript.

"Add me to the growing list of
people who are surprised and pleased to see the fantastic JavaScript...

I have used the debugger in VS2003 Enterprise Architect for years now. It came in handy in the following ways to me.
1) Learning technologies like Ajax where I could step through the code and make sense of the data could be sent and received.
2) But the benefit lies when you are using third party controls for ASP.NET. You can buy the most famous controls and you would find no documentation of client side rendering and manipulation of the controls on the browser end. This helped me debug why things were not working as expected. Lets put it that way, that I found so many bugs that the one of the largest if not the biggest thrid party .NET control company offered me ( a single developer ) money back :)

Try Firebug for Firefox... has breakpoints, and no code changes required :P

... but I see someone already mentioned that... D'oh!