I'm trying to debug some server-side JavaScript code running in Aptana Jaxer and I'm not having any success. I haven't even been able to find any tutorials or posts about this issue. Does anyone know if it's possible and if so, what am I missing?
You can set you Jaxer.Config.DEV_MODE = true; to get some error information in your browser.
Also use the Jaxer.Log to debug.
Hope this helps a bit.
Jaxer and Aptana Studio do not yet have the ability to debug remote scripts from the client side. That is, you can't single-step into a callback and have your code window show you the first line of code in the remote method. This is on their wishlist, of course, but it'd be pretty tricky to do well.
Personally, I use logging. Jaxer has strong facilities for this, in Jaxer.Log.*.
A lot of people sneer at "printf() debugging", but the fact is, it works, and it's often less trouble to set up than an interactive debugger, especially for server applications and remote method invocation. You just sprinkle logging messages wherever you want to know the state of the system at that point, then make your app try to do the thing that's failing. Study the logs, rinse, repeat.
tail -f /opt/AptanaJaxer/logs/jaxer.log
Related
I'd like to output some data to the console or any other visible place to help with debugging. Apparently Logger.log() doesn't do that, or if it does, I have no idea where to see the results (at least in the preview mode).
Is there any functionality for debug output in the server scripts?
I strongly encourage you to check the official documentation to get to know the basics. Using console.log("test") will log anything to the server side logs, which you can access from the preview mode.
I have an puzzling problem. I have a new ASP.NET web application in VS2005 that runs fairly well, but I am having a problem and would like to set a break point to see what is going on. I have compiled the project in Debug mode. I have debug=true set in the web.config. But it appears that the IDE is not attaching to the process at all. Have I overlooked something? I am using the development server and not IIS. This has never been a problem in the past, but is this time.
Have I overlooked anything? Thanks for any help.
Rob
I had this issue a while back with VS2005. I don't remember where I got the following instructions from (copied them to a file which I'm now copying to you) but doing the following steps worked for me. It has something to do with IE8 attaching itself to multiple processes and messing up the debugger. Word of warning, this has you editing the registry, so use at your own risk / take all your normal precautions, etc.
Open RegEdit
Go to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet
Explorer -> Main
Add a dword under this key called TabProcGrowth
Set TabProcGrowth to 0
If you run into the same problem on
Vista or newer, you will also need to
turn off protected mode.
Please note also that I was/am running XP at the time, so I did not have to use the "Vista or newer" clause there. No idea if that has any adverse effects either.
Sorry if I am stating the obvious, but you need to Start Debugging <F5> rather than just running the executable after compiling. Are you doing this?
If you don't hit the breakpoint, you are either not debugging (F5) or your code isn't reached at all. If you want to know which of the two is happening you can throw an exception right at the code where your breakpoint is. If your application is failing at the exception, you know you are not running it with the debugger. If it doesn't fail at the exception you are simply not reaching that piece of code and you will have to look harder for which code you are actually running.
throw new Exception("if I see this exception, I am not running the debugger");
Or maybe you are running two instances of the development server. I've had that sometimes. Look in the Windows system tray for the icon. If you see two (or more) you can right click to stop them and restart debugging.
I have alway tested/debugged my web applications by using f5 to "Start Debugging". Recently (yesterday) I have begun to start without debugging then attach the debugger to the webdev process if I needed to set breakpoints or anything. So far I haven't noticed much of a performance increase when not using the debugger. I am curious about how others save time when running locally. Is it a good idea to only attach the debugger when I need it? Any other options are welcome as well! Thanks!
I don't think you are going to see much of a performance increase. But if you do find yourself frequently attaching to a process manually, you can set up a macro to attach the debugger to whatever process you want to attach to, and then assign the macro to a button or hotkey. I used to do this when debugging old classic asp code, to set up the debugger to attach to IIS.
You can use record macro to create the macro, and then manually edit it if you need to make it more flexible.
Here is a macro I found online you could try as well:
http://weblogs.asp.net/koenv/archive/2008/02/14/quick-attach-and-detach-debugger.aspx
I used to debug like you (i.e. Host the Website in IIS an then attach the debugger) But i've found using Cassini far more productive because of the edit and continue feature, which is an absolute godsend.
iirc webdev == cassini
one other way is to run actual IIS - it's always on, even if you shut down VS, so it may be faster to come up. I am not sure it's actually faster when re-compiling, should be the same or faster. VS2010 supports IIS mode pretty well, plus you get the advantage of being able to test web.config properly, since cassini doesn't support system.webserver portion. We are switching to IIS mode due to url rewriter module, for example.
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.
I was wondering is there is a fool-proof way to run a program on windows such that I'm guaranteed that no interactive dialogs of any kind are displayed.
I've tried the registry ErrorMode hack, calling _CrtSetReportMode(), etc., but they all have holes in them or require you to modify the program.
I need a way to run an arbitrary program and practically force Windows to execute them such that there is no possibility for them to open a window. It is perfectly ok for the program to crash if it attempts to open a window.
Would running the program as a service solve the problem?
I'm not aware of any other ways that might possibly work. Running as a service won't solve the problem either as the dialog will be displayed on the service's desktop, which you generally don't have access to.
You could use a library such as Detours to intercept all calls to functions that might display a dialog box (this might in fact be nearly everything in user32.dll).