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.
Related
Is there any way to access webkit JavaScript and HTTP errors that happen when capturing a page with CutyCapt? I'm trying to debug a thumbnail capture for JavaScript generated documents.
This is not currently possible. I would recommend using a tool like Wireshark to debug any HTTP errors that might occur. It would be easy to add tracing code for network replies to CutyCapt and there are some patches on SourceForge and/or GitHub that do that. I am not sure what could be done to trace JavaScript errors, but ordinarily there should not be any that do not also occur when a page is loaded in a browser. Qt comes with a sample application that implements a rudimentary web browser that could be used for this purpose. I think it also comes with the standard debugger, but I might be misremembering that.
I'm having some problem finding the source of the problem, but here it goes, maybe you know the magic answer.
I'm running this asp.net site with an AJAX updatePanel on my local machine, and everything works just fine, since it's where I developed it. Now, a few days ago, I uploaded the files to my web-host and assigned every single DataBase, and there is no error messages, even though it's still set to debug mode. There is a problem though, whenever I click an element which triggers my asp.net AJAX updatePanel to update, the whole site is updated(which it should not, only the Panel), and my jQuery's (document).ready is called every time as well.
Thank you for any help, I have no idea why this does not work online, nor' do I know why it does work on my local machine.
I have choosen not to upload the code, since I have no idea where the problem might lie, please feel free to ask for the code and I shall reply :)
Have you checked that your web host either:
a) Is running .net 3.5
b) Has the Ajax extensions for .net 2.0 installed
...and that you are testing locally with the same?
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.
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.
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.