Now on to the debugging experience where I have numerous complaints, so I’ll just use a list format:
- Why in the heck did they decide to move the Script Documents treeview node into the Solution Explorer window?It used to be a separate tool window called “Script Explorer”, now it plagues my Solution Explorer whenever I start debugging. This is a huge pain in the rear when you have large solutions and then begin debugging a web page that has a large number of scripts in it. Oh look, I found an explanation here:
“In earlier versions of Visual Studio, client-side script files generated from server-side script appeared in the Script Explorer window. The Script Explorer window was often hidden, so that the availability of client-side script was not always obvious.”
Are you kidding me? Do you know how many windows are hidden inside of Visual Studio until the developer actually decides he/she needs it and makes it part of their default set of windows? That’s kinda the whole point to having a customizable IDE. “Show me the stuff I need, let me hide what I don’t.” This should be put back into a separate Script Explorer window just like everything else… just like it was in previous versions.
- Sticking with the Script Documents, whoever wrote the code to populate/clear that treeview needs to learn a lesson in batch updating of UI elements. Every single node added causes the entire treeview to refresh. When you navigate from one page to the next and it has to remove the nodes it’s the same problem. How about BeginUpdate -> Add/Remove Nodes -> EndUpdate?? If the reason ends up being that the Visual Studio treeview control doesn’t support that (I haven’t done any VS integration projects in a while), then punt the bug to whoever owns that thing and shame them until they add support for it.
// Name: MicrosoftAjax.debug.js
// Assembly: System.Web.Extensions
// Version: 188.8.131.52
// FileVersion: 3.5.21022.8
- Stilllllllllllll sticking with Script Documents and saving the best for last… wtf is with the horrible support for “anonymous code”? Seriously this makes attaching the debugger to certain pages that use controls that declare a lot of anonymous functions (*cough* ComponentArt) absolutely abysmal because it generates a new node in the tree view for every single function. Sometimes attaching the debugger to a page with enough controls on it can take 30+ seconds. The real problem goes back to #2 where the damn treeview repaints itself every time one of these nodes is added. Right now all “anonymous code” entries get added as treeview nodes to the page’s node. My suggestion would be to aggregate all the anonymous nodes under a single node called “Anonymous Code” and that node should remain collapsed by default.
- How in the hell does the bug where you can’t put a breakpoint on the first line of a function still exist?
- Sometimes when you set a breakpoint, Visual Studio decides to add <insert random number here> other breakpoints to locations across all the scripts being debugged at random. This problem also existed in 2005.
- If one of the scripts has a syntax error, the debugger will not jump to the area of the syntax error, but rather it will continue processing and then just blow up on next piece of code that needs runtime access to the types/functions of the file that had the syntax error.
I’m sure there’s more stuff I’m forgetting, but it’s late so I gotta get to bed. If I remember anything else I’ll be sure to come back and update. If you’ve got more scenarios you’d like to join in and rant about, feel free to leave comments. Likewise leave a comment if you have solutions to any of these problems, because I’d love to hear them.