Breakpoints in client side script of .ASPX files

If you open up a .ASPX file from your project, you won't be able to hit breakpoints in the client side script code, like you could for the server side ASP.NET code. The basic problem is that Internet explorer gets a very different view of this file then the version you are looking at. We call the version that you are looking at the server side document, because it’s the text that your web server sees. Then ASP.NET comes along and runs the server side code, the output of the server side code is the client side document. This contains all the client-side script in your .ASPX file, but also lots of other information, like any text from Response.Write.

For classic ASP, the ASP compiler generated a line table for the debugger at the start of the response. To IE, this just looked like a comment, so IE ignores the table. The debugger used the table to map from character offsets in the server document to character offsets in the response. However, due to the compiled (instead of interpreted) nature of ASP.NET, this is a hard problem that the ASP.NET team hasn't had time to solve. In the mean time, there are some good work-arounds.

If you have strong feeling on this, or any other debugger feature, I recommend using the MSDN product feedback center.

Comments

• Anonymous
  August 23, 2004
  So this isn't fixed in Whidbey? I was hoping it would be, as it's really quite a pain. I've taken to putting my Javascript in a separate JS file, which does allow you hit breakpoints as you would expect. But you lose a lot of Intellisense support when you do this.
• Anonymous
  June 02, 2009
  PingBack from http://patiochairsite.info/story.php?id=30043