crminthefield: Where did my scripts go? How to debug JavaScript in CRM 2011 post-UR15

[Blog bot]

Источник: http://blogs.msdn.com/b/crminthefiel...nd-higher.aspx
==============

Chances are, you’ve recently read our Dynamics CRM 2011 Update Rollup 15 overview, read our post covering “what you need to know about UR11CU”, or read a partner blog article discussing UR15.  Each of these highlights how UR15 continues to enhance user experience, be it via the Outlook client or web browser.  As a result, specific changes focused on form load performance have a direct effect on how script libraries are served to the browser.  If you’ve already been developing/troubleshooting JavaScript in an environment updated to UR15, you may have noticed this effect.  Web Resources no longer show up individually by file name in your browser debugger (i.e. Internet Explorer’s F12 developer tools), rather they appear as dynamic scripts.  More on that to come, but first a little background.

Background:

In Update Rollup 12, changes were made so that JavaScript libraries linked to entity forms would be downloaded and processed without blocking the form.  Perceived form load performance increased, but not without a negative side-effect.  Script files weren’t guaranteed to load in a specified order, meaning dependencies between script libraries could lead to intermittent exceptions based on the actual load sequence.  For instance, if the jQuery library takes longer to load than your dependent JavaScript file, any calls referencing jQuery in your form onLoad event handler may throw an “Object Expected” error.

Enter Update Rollup 15 - A Fix:

To address this scenario, Update Rollup 15 again alters the way script library files are loaded to ensure a reliable behavior and address dependency constraints.  While script libraries now load in their intended order, the libraries are treated as dynamic script blocks making for an inconsistent debugging experience across browsers (debugging in Chrome? You won’t see them anywhere, although you can still do live debug by stepping into the functions or forcing a breakpoint in your code).

Form script load behavior by update:

• CRM 2011 RTM through UR11: uses a method that guarantees script library load order and scripts are displayed as named scripts in browser debuggers.
• UR12  through UR14: to increase perceived form load performance, introduces a non-blocking pattern to load custom form scripts which does not guarantee load sequence.  This change produced inconsistent behavior when dependencies exist between script libraries.  
• UR15: uses a balanced approach, derived from the change introduced in UR12, that guarantees the script library load sequence as specified in the entity form definition.  This approach leverages synchronous XmlHttpRequests (XHR) and dynamic script blocks which in turn make browser debugging a challenge.

Now for what you’ve all been waiting for – how to debug entity form JavaScript libraries post-UR15:

Browser Debuggers: Dynamic script content is handled differently across the various browser debugging tools and even between versions.  In the case of Chrome’s debugging tools, you won’t see dynamic script content at all.  But have no fear!  We’ll address circumvent this roadblock by simply traversing up the call stack by one call.  Instead of breaking directly into your function, we’ll start from the point where CRM for script calls custom functions, then step into the custom function.  These calls originate from FormScript.js.aspx.

Note: Another option is to use the debugger statement – by placing it anywhere in a script file it will tell the browser to force a breakpoint and pull open your debugger (as long as script debugging is enabled).  This is not a desirable outcome for production code, so I suggest reserving this technique only for debugging in development environments.  The remainder of this article walks through how to debug without using a debugger' statement, which should be appropriate in all deployment scenarios. 

Debugging script libraries: Previous to UR15, you could simply launch the browser debugging tool, look for a named Web Resource file in the scripts list, and easily set a breakpoint to begin live debugging.  In UR15, the process changes slightly:

• First open your browser debugger (for IE simply press the F12 key), then open the script debugger tab and make sure you’re actively debugging or attached .
• Next, instead of looking for your Web Resource file in the document list, search for and select FormScript.js.aspx
  • TIP: This file may be nested under the edit.aspx file. In IE F12 developer tools, you may have to expand edit.aspx to find FormScript.js.aspx

  

• Within the FormScript.js.aspx document, you will find your custom function call wrapped in an event handler.  For custom functions registered with the form onLoad event, look for the crmForm_window_onload_handler function.  All registered functions will be called, in sequence, within this wrapper function.  For custom functions registered for field onChange events, look for a wrapper function named [attributename]_onchange_handler.  Other form events will have similarly named event handler functions.
• Set a breakpoint within FormScript.js.aspx on your function name.  Now when the event is fired, the breakpoint will be hit before your custom function is called, allowing you the opportunity to step into your function.
  • IMPORTANT: If you have more than one event on the form registered to the same function, there will be a separate handler per call!  You may have to set a breakpoint on all instances or use the wrapping function name to determine if the call pertains to your debugging scenario.

• Trigger the event that you want to debug (onLoad, onChange, onSave, etc.).
• When the breakpoint is hit, press the F11 key to step into your Web Resource code.  From here, you should be in familiar territory – continue debugging as necessary.

That’s it!  Hopefully, these tips have helped your post-UR15 script debugging efforts (and avoided an unnecessary headache).  If you have further technical questions about how to debug, post comments or click email blog author.  I am contemplating the creation of a video to walk through three or four common CRM debug scenarios.  If you would find this valuable, please provide that feedback.  As always, our team of Dynamics CRM PFE’s and Dynamics CRM Developer PFE’s are here to help, either remotely or onsite:

• If you already have a Premier contract let your TAM know you want to work with a Dynamics CRM PFE and they’ll know where to find us
• If you don’t have a Premier contract and you’re interested in Premier support and/or working directly with a PFE, contact us via our Premier Services contact page or reach out via the email blog author page.

Thanks for reading!
Sean McNellis

Follow me: @seanmcne

Microsoft Premier Field Engineer





Источник: http://blogs.msdn.com/b/crminthefiel...nd-higher.aspx