INTRO
Client side debugging improved in the recent years. Visual studio 2008 or later, combined with Internet explorer can provide client side debugging as seambless and as rich as debugging server side code within visual studio.
The problems visual studio had was that server control generated alot of HTML, and in many case generate javascript at run time based on the conditions on the page. Ajax magnifies the problem, adding torturous volume of javascript code to control the user's every interaction with the page. For visual studio, mapping the code at run time to the original source code was a difficult problem; while in server side debugging the debugger can easily map your source code to the code executing at run time. Now microsoft has solved the mapping problem with client side code. Client side debugging in previous versions of visual studio can be left behind, in visual studio 2008 it's a brand new experience.
REQUIREMENTS
Everything required for client side debugging is built in visual studio to just work; out of the box. The only thing required it to enable script debugging in internet explorer; this can be enabled from IE or VS. Note that it will enable script debugging for all pages oppened in that browser, not just when your debugging. This implies that if browsing on the web, encountering a javascript error, a dialog box would pop up. Maybe one solution is to install another browser like safari or chrome to do general browsing.
From the Options-Envrionment-Web browser-advanced-Browsing-Settings(panel)-Disable script debugging(Internet Explorer);Uncheck the checkbox.
Note, Disable script debugging(Other) can stay checked, this is for applications embeding IE, like Microsoft Money.
General reminder, typically if your application is used only in your intranet, IE will be enough, if it is used from the internet, test pages with multiple browsers by right clicking your page and selecting Browse with...
Also, To start debugging, do not use view in browser as the debugger wont be attached.
You can start the application by setting your web project as default project and Debug-Start Debugging.
Notice in the Solution explorer, the Script Documents section that displays documents that contain scripting code.
HOW IT WORKS
When executing code that contains javascript, virtual script files will be generated and added to those Script Documents. Those are generated on the fly by asp.net when using features that require client side debugging.
As a simple test, an application can be written to open a popup window, say hello, update a label to say said hello, and a javascript rollover menu can also be added
When you shutdown the browser, the script documents will disapear from the solution explorer.
In the above example, the aspx file, within a script/script element embeded in the head/head of the aspx, would contain the code to show the alert box, then document.getElementById("yourElementId) and return results, then update the innerHTML of your element with divResults.innerHTML = "your text"
Note that the script in the aspx file will be mapped by visual studio to the actual script within the final document sent to the browser.
LET'S GET STARTED
To start, brefore runing the application, set a breakpoint on the script within the aspx page.
When hitting the breakpoint, visual studio will open it in a dynimic file that it generated by collaborating with Internet Explorer.
You can use the locals window, the visualizer by hovering the variable, if you have the results returned a divResult object, it can be entirely visualized within the Locals window, and also explore methods and events in the div element.
The Immediate window can also be used by typing ? diveRestuls.innerHTML. When shutting down the applicaiton, the windows and dynamic files disapeare, but all breakpoints and openned files will be restored when reopening the project.
The menu control is a .net navigation control and much javascript is generated to implement it. The required behavior are made possible with the asp.net server control generating dynamicaly in Javascript the client side code required to implement the behaviors in the document sent to the client.
That dynamic Javascript is implemented as virtual files that are made available to the browser through a script tag that has a source element that points to virtual script file on the server.
If you view the source of the page when runing in visual studio, you'll see a script element with a source to /ServerDebugging/WebREsource.axd and have various parameters that identify the script file so the client can download it from the server; so thats how the script is included within the page. Those script files are not physical files localted on your server, but are constructed from script files provided by the .net framework, somewhat like a Javascript .net framwork for the purpose of debugging client side script.
It's possible to also debug directly inside the resource files by selecting them in the Solution Explorer and putting a breakpoint at the desired location.
Note that, this client side debugging feature can also be used on older version of the framework, from VS 2008 or later.
REQUIREMENTS AND LIMITATION OF CLIENT SIDE DEBUGGING FROM VISUAL STUDIO
Breakpoints can only be placed within script blocks, you can't set a break point contained in inline script, or in some of the other types of script blocks. Also, for visual studio client side debugging to work, the URL has to contain the page name which can be a problem if working with remapped or redirected urls.
Breakpoint can't set in user controls, master or included pages.
Breakpoint can't be placed in script blocks that have the "differed" attribute set to true.
The id attribute of the script is ignored by visual studio, if an id is specficied for the script element, can't rely on this attribute.
If debugging scripts added from code behind using "register client script block" method, it's still possible to step into that script, just add a line to the script, debugger; this will prompt to attach visual studio once hit. Still required to configured IE and VS2008 for client side debugging as explained above.
Those are minor limitations that can be worked around by creating a test page to test to resolve the bug.
Client side debugging improved in the recent years. Visual studio 2008 or later, combined with Internet explorer can provide client side debugging as seambless and as rich as debugging server side code within visual studio.
The problems visual studio had was that server control generated alot of HTML, and in many case generate javascript at run time based on the conditions on the page. Ajax magnifies the problem, adding torturous volume of javascript code to control the user's every interaction with the page. For visual studio, mapping the code at run time to the original source code was a difficult problem; while in server side debugging the debugger can easily map your source code to the code executing at run time. Now microsoft has solved the mapping problem with client side code. Client side debugging in previous versions of visual studio can be left behind, in visual studio 2008 it's a brand new experience.
REQUIREMENTS
Everything required for client side debugging is built in visual studio to just work; out of the box. The only thing required it to enable script debugging in internet explorer; this can be enabled from IE or VS. Note that it will enable script debugging for all pages oppened in that browser, not just when your debugging. This implies that if browsing on the web, encountering a javascript error, a dialog box would pop up. Maybe one solution is to install another browser like safari or chrome to do general browsing.
From the Options-Envrionment-Web browser-advanced-Browsing-Settings(panel)-Disable script debugging(Internet Explorer);Uncheck the checkbox.
Note, Disable script debugging(Other) can stay checked, this is for applications embeding IE, like Microsoft Money.
General reminder, typically if your application is used only in your intranet, IE will be enough, if it is used from the internet, test pages with multiple browsers by right clicking your page and selecting Browse with...
Also, To start debugging, do not use view in browser as the debugger wont be attached.
You can start the application by setting your web project as default project and Debug-Start Debugging.
Notice in the Solution explorer, the Script Documents section that displays documents that contain scripting code.
HOW IT WORKS
When executing code that contains javascript, virtual script files will be generated and added to those Script Documents. Those are generated on the fly by asp.net when using features that require client side debugging.
As a simple test, an application can be written to open a popup window, say hello, update a label to say said hello, and a javascript rollover menu can also be added
When you shutdown the browser, the script documents will disapear from the solution explorer.
In the above example, the aspx file, within a script/script element embeded in the head/head of the aspx, would contain the code to show the alert box, then document.getElementById("yourElementId) and return results, then update the innerHTML of your element with divResults.innerHTML = "your text"
Note that the script in the aspx file will be mapped by visual studio to the actual script within the final document sent to the browser.
LET'S GET STARTED
To start, brefore runing the application, set a breakpoint on the script within the aspx page.
When hitting the breakpoint, visual studio will open it in a dynimic file that it generated by collaborating with Internet Explorer.
You can use the locals window, the visualizer by hovering the variable, if you have the results returned a divResult object, it can be entirely visualized within the Locals window, and also explore methods and events in the div element.
The Immediate window can also be used by typing ? diveRestuls.innerHTML. When shutting down the applicaiton, the windows and dynamic files disapeare, but all breakpoints and openned files will be restored when reopening the project.
The menu control is a .net navigation control and much javascript is generated to implement it. The required behavior are made possible with the asp.net server control generating dynamicaly in Javascript the client side code required to implement the behaviors in the document sent to the client.
That dynamic Javascript is implemented as virtual files that are made available to the browser through a script tag that has a source element that points to virtual script file on the server.
If you view the source of the page when runing in visual studio, you'll see a script element with a source to /ServerDebugging/WebREsource.axd and have various parameters that identify the script file so the client can download it from the server; so thats how the script is included within the page. Those script files are not physical files localted on your server, but are constructed from script files provided by the .net framework, somewhat like a Javascript .net framwork for the purpose of debugging client side script.
It's possible to also debug directly inside the resource files by selecting them in the Solution Explorer and putting a breakpoint at the desired location.
Note that, this client side debugging feature can also be used on older version of the framework, from VS 2008 or later.
REQUIREMENTS AND LIMITATION OF CLIENT SIDE DEBUGGING FROM VISUAL STUDIO
Breakpoints can only be placed within script blocks, you can't set a break point contained in inline script, or in some of the other types of script blocks. Also, for visual studio client side debugging to work, the URL has to contain the page name which can be a problem if working with remapped or redirected urls.
Breakpoint can't set in user controls, master or included pages.
Breakpoint can't be placed in script blocks that have the "differed" attribute set to true.
The id attribute of the script is ignored by visual studio, if an id is specficied for the script element, can't rely on this attribute.
If debugging scripts added from code behind using "register client script block" method, it's still possible to step into that script, just add a line to the script, debugger; this will prompt to attach visual studio once hit. Still required to configured IE and VS2008 for client side debugging as explained above.
Those are minor limitations that can be worked around by creating a test page to test to resolve the bug.
Comments
Post a Comment