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:
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:
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:
Thanks for reading! Sean McNellis
Follow me: @seanmcne
Microsoft Premier Field Engineer
Nice post , I'm happy to MSCRM back to synchronous onLoad
Very good post,
In FormScript.js.aspx there is my function, but browser (ie12) don't find.
Any else have this problema? Is a rollup 15 error?
Great post and very useful information, thanks Sean. One question, what about Dynamics CRM Online? Are we going to see this new change in Orion?
The load order fix in UR15 is critical to us - glad to see it's been resolved.
But this side-effect of UR15 freaked me out last week when I went to debug a form after applying the update - For a second, I thought my scripts were gone. :-)
Thanks for sharing the explanation and instructions.
(and yes, the videos of the common debug scenarios would be helpful.)
@Toni, try making sure you added the function and published all your changes and it will show up (if you just applied ur15 make sure you have rebooted and try flushing your cache just in case). Finally, if all else fails use the "debugger" statement to force a breakpoint in your code.
@Scott thanks for the comments and I am glad its working!
@R Tebar, I am still looking into it for 2013 but I believe 2013 already respects proper ordering of scripts but did so using a slightly different approach/design. I'll make sure to follow up when I am back in and have some time to test. Thanks!
@Toni, if you had found the function and ie11 didn't break, also make sure you've enabled debugging in the advanced ie options.
Even with "debugger" statement you cannot debug after rollup 15. It does break the execution and you can launch your IDE. But as soon as your IDE launches, script execution continues and there is no debugging in Visual Studio. This is true even for CRM 2013 (new server, no upgrade). This is a huge problem for us now.
If you want to debug using the debugger directive you must have script debugging enabled and a debugger of some kind must be attached to handle the exception on behalf of IE - if VS or IE F12 tools are not attached your breakpoint won't be handled and it will appear as if there is a crash. There are two ways to make sure you are able to break when it hits the breakpoint one is using Visual Studio and the other is using IE's debugger (which is pretty awesome in IE9+). Before you start you need to make sure you have script debugging enabled in IE's advanced options.
1. Use Visual Studio: msdn.microsoft.com/.../z959x58c.aspx
2. Use IE: msdn.microsoft.com/.../gg699336(v=vs.85).aspx
Once I get back to work next week I'm going to try and find some time to record a screencast demo of each way - I'll do my best to get this done within 2-3 weeks. Thanks for reading!
I've finally got around to doing a deep dive on script loading with CRM2013 - here are my results - develop1.net/.../CRM-2013-Script-Loading-Deep-Dive.asp
To answer the question about CRM 2013 - the scripts will not load in the order specified, they are downloaded and loaded in parallel.
Nice post with very useful information, thanks.
The debugging scenarios video would be very useful too, cheers!
Thanks a lot
@Scott Durow - Can you please repost your link; it is returning a ror error. Thanks!
@Sean - Great Post!
@Jason Eldredge - Scott's link is just missing an "x" at the end of the URL: