>
Blog
Book
Portfolio
Search

5/12/2008

4634 Views // 0 Comments // Not Rated

Debugging JavaScript And Script Controls In Visual Studio 2008

As I dig deeper and deeper into AJAX and client side programming in my ASP.NET web apps, more and more logic is being moved from managed code behind my UIs to lose JavaScript files and script controls. Of course, this means that more and more debugging is going to have to be done in non-managed source code files. And not being able to debug your code really takes the fun out of programming. It's pretty much like Moses telling the Israelites that they had to make bricks without straw!

In Visual Studio 2005, (which is the Old Testament to Visual Studio 2008's New Testament (no more Biblical references, I promise)) debugging JavaScript meant moving the code from HTML and placing it in a .js file that is included in your app via the Script Manager. That code looks like this:

Code Listing 1

  1. //registration
  2. if (!this.Page.IsPostBack)
  3. {
  4. //register javascript
  5. ScriptManager sm = ScriptManager.GetCurrent(this.Page);
  6. if (sm == null)
  7. throw new Exception("This control needs a Script Manager on the page.");
  8. else
  9. {
  10. ScriptReference script = new ScriptReference("Scripts/SomeAwesomeScript.js");
  11. if (!sm.Scripts.Contains(script))
  12. sm.Scripts.Add(script);
  13. }
  14. }

This way, you can place breakpoints in the .js file and they would magically fire. You then have full use of Visual Studio's powerful debugging tools, such as the Immediate window, Watches, and the ability to mouse over a variable and see its value. This is really key; if Microsoft wants us to write more client side code, then we had better have all the weapons in our arsenal to be able to debug it!

"Edit and Continue" also still kind of works. If you change code in a .js file (or even markup in an .aspx or .ascx), just save the file, and refresh the page in your browser. Visual Studio's debugger stays attached, and you can very quickly tweak your UI in this manner.

However, in 2005, I never found a good way to debug the client side of my Script Controls I reverted to the old-skool method using alert() boxes to pop up values. The problem here is that the .js file of a script control is included as a web resource, and not just directly interpreted by the browser. This is cool since it is faster and less sloppy than loose JavaScript files, but therefore there are no loose JavaScript files to debug!

Then, I noticed the following during one of the first times I debugging code in Visual Studio 2008:

Script Documents

What the heck? Script Documents? At first glance, I wondered what someone on my team included in the solution. But then I realized that 2008 was actually keeping track of all the files that IE was browsing! This way, you can see how ASP.NET rendered your pages (which is pretty interesting) and see everything else that's going on.

This is awesome, because although I totally embrace new technology doing menial tasks for me, I hate when too much is going on behind the scenes...especially to the point of me not understanding how something works. Visual Studio 2008 is un-abstracting all the magic that ASP.NET does to convert our managed code to web pages.

So if you need to debug a .js file in a script control, just find the resource in this list, and double click it. VS will open it as a JavaScript file that you can put breakpoints in, and get the full developer's debugging experience! Have fun!

3 Tags

No Files

No Thoughts

Your Thoughts?

You need to login with Twitter to share a Thought on this post.


Loading...