Debugging with Visual Studio

 

Think about how debugging Web pages works: When you're doing Web development, you're likely coding for both server-side (using, for example, ASP.NET and C#) and client-side (using JavaScript). The C# code runs on the server, and the JavaScript code runs inside the user's browser. When you're debugging, you're probably running both the server and client browser on a single machine.

For debugging server-side code, Visual Studio hooks into the IIS server, letting programmers set breakpoints and step through the server-side code. Such breakpoints typically occur as a result of the user interacting with the Web page; during this time, the browser will be waiting for the server, unaware that the server is being debugged. (In that case, Visual Studio must either be on the same machine as IIS, or set up to remotely debug.)

But to debug client-side, developers need to set breakpoints that cause the browser itself to pause and wait for the debugger. Given that, the browser must be aware of the debugger and be on the same computer as the debugger.

That means if a developer has a single instance of Visual Studio running, then it needs to be aware that it's potentially debugging two separate processes: the server-side (through IIS) and the client-side (through the browser).

There are different ways to debug JavaScript-for one, simply putting the debugger; statement right in the code. But for that to work, the browser needs to know to let Visual Studio kick in. Internet Explorer does, but other browsers don't automatically know about Visual Studio. Even then, IE will ask which instance of a debugger to fire up.

Instead, a good way is to set a breakpoint in the code (by right-clicking and clicking Insert Breakpoint in the context menu). Then set the HTML page you want to test out as the startup page (by right-clicking the page name in Solution Explorer and clicking Set As Start Page). Make sure the project is set up to use IE as the default browser (by right-clicking on the HTML file in Solution Explorer, and clicking Browse With. In the window that opens, click Internet Explorer, and then Set As Default. Close the window by clicking the upper-right button; don't click Browse, as you don't want to open the page from here, because it won't be set for debugging.) Finally, press F5 to start up the debugger in Visual Studio.

At this point, things worked really well. I set a breakpoint on the first line inside my function. When I typed something into the Web page and clicked the button, the page waited as Visual Studio activated with the code waiting at my breakpoint's line.

From there I could do all the usual debugging goodies, like float the mouse over one of the identifiers (such as document), which resulted in a popup showing me all the members. This time, the debugger is hooked into the JavaScript engine and can read the values; I can even change them as I should be able to do with any good debugger.

All is cool so far. Now let's try out the jQuery support.