In order to debug an asp.net web app I have to have IE Script debugging enabled. Unfortunately, in the past week or so google's analytics javascript has developed a problem. So that when I browse to a site that has google analytics I receive the little pop up "A runtime error has occurred. Do you wish to debug?"
Yes, even stackoverflow is affected.
This is a tremendous pain in the butt. Is there any way to keep IE Script debugging enabled to keep the .net debugger happy, but get rid of the pop up?
I would suggest using IE for debugging purposes only, and Firefox for darn near everything else. Your life will benefit from this.
Script Debugging is not required to debug ASP.NET pages, it is only required if you wish to stepthrough script errors, you can disable this option in IE and still debug your server code fine. Unfortunately it is an IE wide option so if it's on it's on and if it's off it's off.
But disabling the option will not prevent you from debugging your asp.net applications.
Are you debugging javascript behaviour specifically in IE? If not, get Firefox and Firebug. Javascript debugging in IE is painful, and should only be resorted to in situations where you're trying to fix IE idiosyncrasies. You don't need script debugging enabled in IE if you're just debugging web forms.
You could write some code to make a change to the following key in the Registry
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Disable Script Debugger
Depending on how you have your project you might be able to tie it to the actual build (via a Macro), or if anything just put it somewhere in your Application_Start event.
Returning back to normal might be a little more difficult. Potentially you could watch for the iexplore.exe process and when it dies you revert it back.
Hope that helps.
Related
What is the best approach to similate a browser full cache when debugging a Silverlight or ASP.NET application? There is some intermittent behaviour that I want to make a determination if browser cache or full cookie cache is playing a part in this behaviour I am seeing.
Thanks for the help, in advance :)
You can not simulate IE cache that and at the same time debug your application and break point whats on code behind (if I understand well).
What you can do is to use the Debug.Write(string) functions inside your code to read whats going on, and you can read the out put of the events using the DebugView from sysinternals:
http://technet.microsoft.com/en-us/sysinternals/bb896647
I have a simple asp.net website.
In JavaScript, I added a handler to the window.onerror event.
When I debug in Visual Studio, their handler seems to override mine. When any JavaScript error occurs, it enters their debugger and my onerror function never gets called.
Is there anything I can do to make mine still operate without disabling client side debugging?
I am afraid that client script debugging in Visual Studio is all or nothing. VS hooks JScript in the IE that is launched on debug there are no configurable options in how it handles js errors.
I completely understand your question and why this is a big deal. The only real option for testing your client side error handling is to use venkman, jetbrains (they have a new web centric ide) or some other js debugger.
Not telling you anything you don't already know, just confirming it. ;-)
Let me know how you eventually decide to handle this.
There is a class library project with embedded javascript file, with a lot of functions (clint-side implementation), is it possible to debug them?
If I set breakpoints inside this file, they never break.
You can, but there is some setup involved - there's an explanation here:
http://weblogs.asp.net/scottgu/archive/2007/07/19/vs-2008-javascript-debugging.aspx
Once set up it works pretty much the same way you'd debug server-side code.
Edit: I should add that it depends what you're doing as to where is the best place to do your debugging. If you're strictly doing client side debugging then I'd suggest using Firebug etc as suggested by the other answers, if you're moving between client and server side code then it's less clumsy to use the Visual Studio tools as above.
You need to debug javascript client side with something like Firefox/Firebug, FirebugLite, or IE8 Developer tools.
Debugging JavaScript has to be done via the client. Breakpoints in the back end would never be triggered because the back end never actually runs the code.
The method for debugging JavaScript varies by browser. For Internet Explorer, there is an Internet Developer toolbar and a Script Editor that will help. For Firefox, tools such as the FireBug addon are very helpful.
If you don't know what the operation aborted error is, here's a Microsoft KB Article about it, http://support.microsoft.com/default.aspx/kb/927917 . There's also tonnes of posts about it but the simple answer for it's occurrence is this; the error only occurs if you try to manipulate a DOM element via JavaScript before the element you are trying to manipulate is loaded.
I know how Internet Explorer's (IE) infamous Operation Aborted occurs and know how to fix it. The problem I have is a very weird scenario. Testing locally and on a development machine with IE7, I never ever get the operation aborted error (both sites running as http).
However on our client's testing site it occurs all the time. Unfortunately my testing environment is not the same as the client's testing environment, so that adds some variables to the mix, but the main difference I see is that the client's testing site is using SSL.
Has anyone ever had the Operation Aborted error only for an SSL site?
The other thought that popped in my head was that it was a latency issue. Locally the site loads up almost instantaneously whereas on my client's testing site, the page loads slower. So with that in mind, I got Fiddler running and simulated the performance to run at old school modem speeds, still no operation aborted error locally or on our own testing server.
FYI: The site is an ASP.NET 2.0 Site using ASP.NET AJAX Extensions 1.0. The page with the issue also has the AJAX Control Toolkit's Cascading Drop Down on it.
And yes as far as I can tell all JavaScript that manipulates the DOM is at the end of the markup, not the beginning.
Any help or comments is greatly appreciated.
Well after scouring the Internet I found the issue. It has to do with a bug in the the ASP.NET AJAX client-side framework.
I'll paraphrase what I found:
The issue is a race condition that occurs due to an Internet Explorer/ASP.Net AJAX bug. The probability of encountering this issue increases when the application has a significant number of ASP.Net AJAX enabled server controls on the web page. The issue is explained here, http://seejoelprogram.wordpress.com/2008/10/03/fixing-sysapplicationinitialize-again . I have added this fix to the project I'm working on.
This fix is still required if using ASP.NET 3.5 SP1.
I guess the reason why you don't have SSL on your test box is due to the cost of the certificate. Did you know you can get Free short term certificates? I've often used them to sort out issues like this.
For example RapidSSL do a free 30 day certificate.
I'm new to ASP.net but not to C#, .net or Web Development.
In PHP it was nice to be able to go right to the browser and refresh whenever I made a change. Using ASP.net with VS08 however seems a bit awkward.
Should I launch a development server and keep it open, refreshing the browser when I make a change or should I close the development server between editing code?
Sorry if this sounds silly but I'm just not sure what the "accepted" practice is here.
When developing with Cassini, I always just let it run as it saves the startup time whenever I want to debug. It doesn't hurt to do so, it'll always reflect the current built DLLs and works pretty well.
You have two options when going from Visual Studio to the browser. The first is to debug the application by pressing F5 and running it. The second is to choose the "View In Browser" command (or use the keyboard shortcut Ctrl+Shift+W). The latter doesn't attach debuggers to the web server which makes it much faster than debugging but doesn't support things like code-behind break points or breaking into code upon unhandled asp.net excpetions.
For fastest development, minimize the number of times that your web server is started and how many times you attach the debugger to the web server.
I launch my dev server and then leave it running all the time. Instead of closing down the dev server, I detach the debugger, and when I need to step through code I attach it again. This gives me the best of both worlds: saves me the web server startup time AND runs pages fast most of the time.
Depends what stage of development I am in.
If I am adding lots of files (something that you can't do in Debug mode), changing lots of code in App_Code (which will reset the app) or adding lots of components from the toolbox, then I will tend to leave Debug off.
Once I start actively debugging a site, then I will leave it on as much as possible.
I use IIS even for development so there is no "launch" of the web server at all. That being said, I will typically alt-tab between code I'm working on and the browser window while I am fine-tuning HTML, Ajax calls, or the code behind. Bigger changes require a restart and you will receive a message that the code is no longer in synch with the web site (during an exception) when you must restart.
The bottom line: you can debug while running in an ASP.NET application and, as long as you can get away with it, it is an effective way of tuning your software.