Visual Studio Script Debugger and Microsoft Script Debugger Mixup
Over the last couple of days I’ve been working on client side stuff and have been experimenting with a few different tools for editing and debugging JavaScript. Somewhere in there I installed the Microsoft Script Debugger ontop of the Visual Studio installation (for another tool that needed the script debugger specifically).
Both can co-exist but when you install the Microsoft Script Debugger it takes over script debugging for the machine and dumps Visual Studio out of the loop. So I uninstalled and now I am getting the standard IE error:

This dialog is a pain to read and well, you can’t debug from it.
So how do I get Visual Studio Script debugging back? The key’s in the Tools | Options dialog where you can choose VS.NET as the default script debugger for your system.

You turn a setting in one place and it updates another setting in a completely different place. Intuitive, n’est pas? <g>.
Hopefully this save somebody else a few minutes...

var Callback = new wwCallbackMethod("LookupPanel","SimpleMethodCallbacks.aspx");
debugger;
Callback.postbackMode = "POST";
Callback.CallMethod("AddNumbers",[203.12,213.11],TestCallback,OnError);
Other Posts you might also like
The Voices of Reason
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
I'm sure we'll eventually get a decent environment for this in Orcas. You might want to check the previous post regarding JavaScript editors. Some of the environments there integrate debugging into the environment (or claim to anyway <g>).
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
Also, I suspect your VS crashing is possibly a Vista problem? I've been using VS to debug JS for quite a long time and haven't had it crash on me once yet (XP Professional) unless I try and do a quick view or add a watch on a method that opens a Modal Dialog.
I have great expectations for Orcas, lets hope it doesnt dissappoint... I'd also like some better debugging support for windows services, it seems a great effort to re-install the service everytime some small bug works its way into the service somehow. I'm sure there's an easier way, I just don't know how yet
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
* You have to create a bogus site it set breakpoints before launching a page(re-launching that is). No I don't want to have to modify the source to debug with the debugger keyword.
* You can't break on the first line of a function.
* It's for code, and oblivious to CSS and HTML.
* Browsing nested data structures isn't very good.
Actually it also has one other nice feature. Set next statement, which lets you repeat or skip code lines.
Firebug only pauses the current event handling when reaching a breakpoint, which means that you get out of order execution. Personally I haven't found it a big issue once I understood what it was doing.
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
Thanks Rick. A really helpful post. I unistalled Microsoft script debugger and since then there was no way I could have debugged the script. I re-installed the debugger and followed the steps you mentioned (tools/options) and it worked..
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
Error.
'Attaching the script debugger to [2844]iexplore on machine 'MechineName' faild. A degugger is already attached. '
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
Error.
'Attaching the script debugger to [2844]iexplore on machine 'MechineName' faild. A degugger is already attached. '
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
Error.
'Attaching the script debugger to [2844]iexplore on machine 'MechineName' faild. A degugger is already attached. '
# re: Visual Studio Script Debugger and Microsoft Script Debugger Mixup
And the debugger; keyword was one of the better finds this year. You're right that almost nobody knows about it, in fact, one of the people i work with used to physically call methods that he knew didnt exist simply so he could get a fake "breakpoint". The problem then was that you cant step past the point to see what is still going to happen like you can with debugger. Needless to say, I was thanked :)
Another possibly less well-known (nobody at my office knew this, not sure if that says something bad about my office or not :P ) debugging tip (for sql scripts though) is that you can step through stored procedures using Query Analyzer. Right click on the procedure you want to debug in the object browser and select debug.