Debugging tools and tips for ASP.NET applications

When I develop ASP.NET applications or test my controls I make use of some tools which I thought would be useful listing, along with some tips.
  • PocketSOAP TcpTrace and ProxyTrace are very simple tools which let you see the traffic flowing between you and a server (a local server too) in a raw fashion. They're almost identical in that they show what's passing through them, but when ProxyTrace acts as a proxy server (you choose a port to listen on and configure your browser to point to it), TcpTrace lets you choose both the port to listen on and the destination server:port pair; then it will redirect all the traffic coming from localhost:SourcePort to DestinationServer:DestinationPort.

    I mostly use TcpTrace because it's faster to set up since you don't have to change the browser settings to make use of a proxy server. Suppose you are developing a web application with ASP.NET and want to see what's flowing between your browser and the ASP.NET Developement Server which comes with Visual Web Developer (asynchronous traffic too). As you know the VWD server starts on a dinamically chosen port, in order not to collide with other instances eventually running already. So you hold CTRL + F5 to start the all the stuff and you'll see that the browser points to http://localhost:SomePort/VirtualDirectory/PageName.aspx , where SomePort is the port it is listening on (in my case, at the moment, 3862). Now, in order to analyze the traffic, start TcpTrace and you are prompted to insert at least three parameters that you can set as follows:
    • Listen on Port #: set it to an arbitrary number, this is the port you will point to with your browser. For example, 8080, but anything goes.
    • Destination Server: set it to localhost.
    • Destination Port #: set it to the value SomePort we saw before. It is the port the VWD server is listening on, in my example, 3862.
Click OK and you'll have TcpTrace listening on port 8080 and redirecting to port 3862 (and vice-versa). All that's left to do is set your browser to point to the new port, so you'll change only the port of the url from SomePort (3862) to 8080. Hit Enter and you'll be able to see all the Request/Response pairs in the TcpTrace GUI.
These are very simple tools, and will let you see only the raw data, but they are as simple as useful.
  • Fiddler is a more advanced tool for debugging HTTP traffic. It acts in the same way as ProxyTrace does, except that when started it automatically configures Internet Explorer to make the traffic flow through the port it listens to (by default, 8888). In case you want to use it with another browser then you'll have to set its proxy settings to point to that port. Fiddler even installs itself as an IE plugin, so that you can start it directly from there.
    Fiddler has many more features than the PocketSOAP suite, and the one I use most is its ability to show much more data about the Request/Response pair. In fact, it can show Request data as Headers, Text, Forms, Hex, Raw and Xml, and Response data as Headers, Text, Image, Hex, Caching, Privacy, Raw, Xml. It can even edit the response data, for example applying compression.
    Another nice feature is the SyntaxView format, which is achieved installing a plugin which is available on its website and which shows Response data in the same fashion as you see it in the VWD editor. Very cool.
    If you need advanced features Fiddler is absolutely the choice.
  • Internet Explorer Developer Toolbar and Firefox Web Developer Toolbar are two toolbars with so many features that would take a book to describe them all. They are a must have for web developers. Among hundreds features, validation of markup, CSS, accesibility and so on as well as partial page source view (remember Ajax?). Just check them out and you'll see how useful they are.
  • TamperIE and Tamped Data are two addins respectively for Internet Explorer and Firefox which allows editing the data submitted to the server either by GET or POST request. While GET requests can be easilly edited by hand since the name/value pairs are appended to the url, POST requests require such tools to be edited. Ok, maybe you thought you didn't need to validate POST data on the server because there was no way of tampering with it?...
  • ieHTTPHeaders is an Explorer Bar for Microsoft Internet Explorer that will display the HTTP Headers sent and received by Internet Explorer as you surf the web. It can be useful in debugging various web-development problems related to cookies, caching, etc.
  • Full Source is an Internet Explorer menu extension which displays the source Internet Explorer is displaying, directly from the Internet Explorer object model. This is useful wherever javascript is dynamically writing HTML into the DOM, or where XSLT has been used to generate HTML.
  • JSLint is a javascript code verifier. It's written by a JS guru, Douglas Crockford. When you write Javascript, you should use this online tool to verify its correctness. Besides checking the code for errors, it suggests best practices and common subtleties and supplies a lot other infos on the code.
  • Web Developement Helper by Nikhil Kotari is an Internet Explorer plugin that provides a set of useful tools to both Ajax/JavaScript developers as well as ASP.NET page and control developers.
Finally, just a couple of tips for debugging Javascript with VWD or Visual Studio 2005. When you start in debug mode (F5), you can see a window called Script Explorer (if not, you can show it up with Debug -> Windows -> Script Explorer). In that window you can see all the client-side code you can break into with breakpoints. As far as I've experimented it's a bit buggy, but sometimes it comes useful.
Another way of debugging Javascript is to write the keyword "debugger" in your script files. When you then enter the debug mode, the execution breaks exactly where you placed the keyword, so that you can debug your script starting from there.

kick it on DotNetKicks.com

Published 24 July 2006 09:13 PM by simoneb
Filed under: , ,

Comments

# DotNetKicks.com said on 24 July, 2006 03:15 PM
You've been kicked (a good thing) - Trackback from DotNetKicks.com
# Sonu said on 24 July, 2006 03:17 PM
Nice list. I would also suggest the JavaScript Debugger extension for Firefox.
# simoneb said on 24 July, 2006 03:24 PM
Hi Sonu, thanks. Yes I used that tool in the past but I found I didn't use it much since I mostly debug Javascript within Visual Studio. Another one which maybe is worth trying is FireBug, another Firefox extension.
# Sonu said on 24 July, 2006 03:37 PM
Yeah Firebug is good as well, but I like the style how the IE Developer toolbar works - though Firefox is the better browser.
# simoneb said on 24 July, 2006 03:41 PM
Eheh, don't you care about your MVP status? :)
# Sonu said on 24 July, 2006 03:44 PM
I am not afraid about that :)
# simoneb said on 24 July, 2006 03:48 PM
Just kidding of course ;)
# Moni said on 26 July, 2006 04:26 AM
I wish there was a way to speed up the write -> build -> debug cycle. Everytime I  push the "start" button it takes forever to compile, cache, etc. Anybody got a good tip on that?
# Sonu said on 26 July, 2006 09:32 AM
If its a large project, you should make sure that "Enable Incremental build" is checked (Project->Project Properties->Configuration Properties->Optimaztions).

This will compile only the changes not the complete project.
# Moni said on 27 July, 2006 02:49 AM
Thanks for the tip!

The switch is already on for my projects (seems to be the default). Actually I'm annoyed at the fact how VS decides to cache everything when a website is being opened. It copies a bunch of files with funny names into a temp directory. That seems to take the longest and it totally unnessary to me.  

Ok. I'm using VS2003. Moving to VS2005 soon. VS2005 seems to be able to handle this better.

Anyways thanks,

Moni
# Deepak Trama said on 02 January, 2007 10:36 AM
HttpWatch

This site

Search

Go

This Blog

News

Syndication

Sponsors

  • MaximumASP