Quicky: Step through Javascript in Visual Studio

After you hit "F5" (run in debug mode) and get the website running, go the page in question that should be running your javascript. Go back to Visual Studio > Solution Explorer  > Script Documents > Windows Internet Explorer you will see all the scripts that are currently running.

In that section, if you scroll down you should either see the name of the page or default followed by some text (ie: default?dzHbakj3kj09d0dflkjb_lk2j3jlkj)

Open the file and place your breakpoint(s). Allowing you to do quickwatch or to view the data.

 

Some additional methods on stepping through and debugging Javascript:

1. If you have VS2012 there is the DOM Explorer: http://msdn.microsoft.com/en-us/library/windows/apps/hh441474.aspx
2. Using the "debugger" keyword in javascript (http://www.aspsnippets.com/Articles/Debug-JavaScript-and-jQuery-using-Visual-Studio-in-Internet-Explorer-browser.aspx)

JavaScript has a debugger keyword which can appear in JavaScript source. Older JavaScript engines will flag its use as a syntax error (use of a reserved word). But newer engines will allow the keyword. Engine embedders can install a callback hook to be called if and when the keyword is reached during script execution. At some future point there may be a JavaScript Debugger which will install such a hook and pop up a fully featured debugging window when this event fires. For now I have created such a hook in xpconnect which is set in DEBUG builds only. If the debugger keyword is reached then the JavaScript stack will be dumped to the native console (same as if DumpJSStack() had been called.  

After hitting the debugger keword and dumping the JS call stack, JS execution will continue as if nothing unusual had happened. If you would like this to stop in your native debugger then set a breakpoint in xpc_DebuggerKeywordHandler in your native debugger. The debugger statement can be very useful as a kind of super dump as you develop your JavaScript code. You can also use it as a kind of assert: if(some_unusual_condition) debugger;

Note 1) in the example above the test will always happen even though debugger might have no effect in non-DEBUG builds 2) at some future point someone is bound to ship a JavaScript Debugger that will catch these cases (even in non-DEBUG builds). When that happens, users trying to debug their own JS code might trip over your debugger statements. So, while these debugger statements might be very useful as you write code, you may not want to leave them in permanently.  

- Mozilla http://www-archive.mozilla.org/scriptable/javascript-stack-dumper.html

 

Debugging Interop in SSIS

Had a little trouble getting a COM (interop) dll/tbl from working in a SSIS's script task, while a similar program in a normal C# project would run sucessfully.

First thing I did was a quick registry hack to turn logging on for interop:
HKEY_LOCAL_MACHINE/SOFTWARE/MICROSOFT/Fusion

and created a new DWORD called EnableLog
and set the value to 1

This then gave me more info when I ran the package "without debugging".

In this case, it was having trouble finding my interop dll, because it was looking in the SQL-Server and .Net directories instead of the build directory.

So, as a quick solution, I copied the interop dlls from the build directory and drop them in the necessary folders:

C:\Program Files\Microsoft SQL Server\100\DTS\Binn\

-and-

C:\Windows\Microsoft.NET\Framework\v2.0.50727