I have a .js file that normally gets executed by cscript.exe (i.e. is not run in the browser and cannot be run there).
I know, that I can feed cscript.exe the //X parameter in order to get asked for a debugger to choose. Ok. That's fine.
I select "Visual Studio 2005 Debugger", IDE comes up, execution stops on the first line. Fine.
Script terminates (or I terminate it), I edit something and want to debug it again.
Simple thought would be just to hit F5 and run the debugger again. But this doesn't work. VS just tells me that it couldn't find any debugging symbols in cscript.exe:
What now? Starting cscript.exe from the command line again for each debug run is quite cumbersome in my opinion.
Is there a way to simply debug the script with VS? Also hints for other debugging tools would be appreciated.
Edit:
The answer of t0nyh0 is pretty close. I create a dummy console application, compile and the debugger comes up. However, two things are not perfect
cscript.exe always asks for the debugger to use (which instance of VS).
Could this be overcome by specifying a certain debugger instance directly in the command line?
In order to fire a post-build event, there have to be some modifications in the sources. Currently, I simply add/delete a blank line to trigger building of my dummy project.
Is there a way to always execute the post-build script, even if nothing has changed?
There might not be a way to attach the debugger to cscript.exe itself, but you may be able to create a post-build event that runs a batch file that executes the cscript.exe //x myScript.js command so that every time you build, it executes for you automatically.
See this for more information on post-build events: http://msdn.microsoft.com/en-us/library/ke5z92ks(v=vs.80).aspx
While not a debugger tool, you should consider using a JavaScript testing framework for Visual Studio, such as Chutzpah, which will most likely make your life a lot easier.
Along with standard browser debugging tools (Firebug or Chrome Inspector), I've found that's all I usually need to build clean, tested, mostly-bug-free JavaScript code.
I don't have cscript at hand, but I think you can try to attach VS to the process manually.
After you start up your js using cscript.exe //x myScript.js, click "Debug - Attach to Process", find your cscript.exe process and attach to it.
I forget if VS2005 has this function but VS2008 and VS2010 do.
It is the native debug action that VS takes to debug (attach to the running process). If this doesn't work, I don't think you can do this using Visual Studio.
Best Javascript Debugger is Rhino Debugger See http://www.mozilla.org/rhino/debugger.html .
it is open source and you can get the source code of the Debugger GUI.
you can customise it as you wish :-) .
Related
I have been using the Brackets editor for writing html- and js-files and testing them in Chrome with the live preview (having a server and using localhost, whatever the inner-workings of that is).
Recently this process called "node.exe *32", "Node.js: Server-side Javascript" has been running and taking up all the processing power (or 50% but I guess it's only because it uses one core(?)). Of course this makes the program totally unusable because in the long run it will heat up my laptop and perhaps destroy it permanently (luckily I have Core-Temp that will warn me when it overheats if I don't notice it).
The process won't shut off even when I close the editor and I have to kill it from the manager. Sometimes the things I'm doing in Brackets won't work when I kill it (and try and continue to use Brackets) but for example now that I tested everything seems ok even after killing the node.exe process.
What is causing this and how to stop it? Or what would be some other editors where I can write html, css and js files and test them in Chrome with a push of a button?
EDIT Again the program won't work after the process is killed and now the process even seems to be reborn whenever I kill it. It must be a virus of the most malicious kind???
I "solved" it myself by renaiming node.exe in the Brackets folder to something else. Now it won't run but at least the live preview still works. Don't know if xhttpxml-requests or that sort of cross-origin -stuff will work but it's OK for now if I don't use them.
Oh, it's just the file://... in the address bar so it's like not running the server I assume, so it's the same thing that I just opened the file to Chrome "as is". Well, at least I can now use the editor.
Still would like to know some answers.
Possible to set a breakpoint for the code block of javascript like the screenshot below.
How can we use them? VS always ignores.
If Internet Explorer is set as the browser when debugging, Visual Studio is, in theory, able to stop at breakpoints set at client side script. To use the feature, you will need to make sure that "Disable script debugging" is checked in your IE Internet Options, Advanced tab.
However, I have found VS script debugging to be a bit flaky; the breakpoint is not always hit, especially with VS2010 or earlier. My personal experience is that it works best in VS2012 or later.
That being said, if you're using VS as the client-side script debugger and you find that your client-side breakpoints are not getting hit, it is best to insert a "debugger;" line prior to the line you would like to break at to ensure that it is picked up by the VS script debugger.
pennstatephil posted a link above that indeed provides more information on the subject: http://msdn.microsoft.com/en-us/library/7seh8d72.aspx
Edit: I'm not able to add comments, but in response to sb9's comment about why one would use IE, I find debugging in Visual Studio a lot more convenient when investigating script behavior before postbacks occur and server-side behaviors occurring immediately after postbacks. Also, sometimes the VS/IE combination will catch errors that Chrome and Firefox/Firebug reports with a nonsensical error message.
In Visual Studio 2017 there is an option to enable/disable script debugging
Just enable it and you should be good to go.
There are seemingly infinite possibilities to why this happens. I just solved this problem after hours of searching.
My particular issue is that my breakpoints were disabled immediately after my coworker enabled bundling (see description here). I had to go into our BundleConfig.cs file and comment out the line that said:
BundleTable.EnableOptimizations = true;
After I did that, they were hit. You'd want to add that line back in for deployments.
Another scenario for the inability of the debugger to stop at the break point is if one uses bundling.
To debug JavaScript files, we need to remove bundling.
I hope this will help someone.
Yes you can put the break-point on client side page in Visual studio
First Put the debugger in java-script code and run the page in browser
debugger
After that open your page in browser and view the inspect element you see the following view
I have a page that has a byzantine amount of JavaScript code running. In Internet Explorer only, and only version 8, I get a long-script warning that I can reliably reproduce. I suspect it is event handlers triggering themselves in an infinite loop.
The developer tools are limping horribly under the weight of the script running, but I do seem to be able to get the log to tell me what line of script it was executing when I aborted, but it is inevitably some of the deep plumbing of the ExtJS code we use, and I can't tell where it is in my stack of code.
A way of seeing the call stack would work, but preferably I'd like to be able to just break into the debugger when I get the long script warning so I can just step through the stack.
There is a similar question posted, but the answers given were for a not-the-right-tool, or the not terribly helpful advice to eliminate half my code at a time on a binary hunt for the infinite loop. If my code were simple enough that I could do that, it probably wouldn't have gotten the infinite loop in the first place. If I could reproduce the problem in Firebug, I'd probably be a lot happier too.
Here is what I would do:
Go to http://www.microsoft.com/whdc/devtools/debugging/default.mspx and install the Debugging Tools for Windows. You want to run WinDBG when this is installed.
Follow the steps outlined at http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx#a to setup the symbol server connection and have the symbols automatically downloaded to your local drive (c:\websymbols -- or whatever).
Run IEXPLORE.EXE under WinDBG. The help file should give you assistance in doing this if necessary. You need a couple of commands once you get Internet Explorer running and such. First, go ahead and get that large script going.
Break into the debugger (CTRL-SCROLLLOCK to break).
a. Do a LN to "list nearest" to get the DLL files that are loaded. Hopefully, you'll have JSCRIPT.DLL loaded in memory.
b. Type .reload /f to force the reloading of all of the symbols. This will take a while. Now, after this is done, type LN again and you should see that the proper JSCRIPT.PDB has been downloaded to your system in the symbols directory you setup earlier.
Depending on what you want to do, you may need to restart the debugger, but you can do this: After the initial break on WINDBG load, you can type "sxe ld jscript.dll" and it will break when jscript.dll loads.
This is the tricky part, because once this loads, you don't have the code for jscript.dll, but you have the proper symbols (if they are not loaded, then reload them with .reload /f). You can view the functions available by typing "x!jscript" and you'll get a full list of all of the functions and variables.
Pick one, set a break point, and then you should be able to track what is happening to your script.
If nothing else is accomplished, by using the .reload /f process, you can get the appropriate jscript.pdb files loaded on your system. It's possible you could use these in conjunction with Visual Studio to do additional debugging in that manner, but I'm not so sure how well that will work.
I've run in to this before and have had some luck with enabling the developer tools along with Visual Studio. When an error is encountered the page loading is halted, and I could then load up Visual Studio to see the specific line causing the trouble.
This site has some information on using Visual Studio along with the Internet Explorer debugger: Using Visual Studio to Debug JavaScript in IE
I am writing in javascript for windows (and also in wsf using javascript and vbscript) a desktop script not for internet and not using any explorer.
I need tool for debugging (free one).
Does someone can recommend on one ?
Thanks
I'm assuming you are creating WSH scripts based on your description. In order to debug WSH JavaScripts, start your script with wscript.exe /d path to WSH file after that, whenever an exception is going to occur, you are going to be presented with a choice to debug the script with Visual Studio or Microsoft Script Debugger (free). If you just want to step through the code start your script with wscript.exe /d /x path to WSH file this will cause an exception right at the begging of your script execution.
More information here
Aptana Studio is a great Eclipse extension and can also debug Javascript
I've heard Firebug Lite could do this? That's probably not what you're looking for still.
From the question, it sounds like you are trying to make an AJAX app that perhaps loads from local javascript + HTML.
That said, if it is OK to use Firefox as the web client, you might try Firebug. It is an excellent javascript debugger. It lets you do usual step / breakpoint things, inspect variables, and display the current page as a DOM model to help see what your jQuery (or Prototype, in my case) queries will find.
I've got a rather hideous and large javascript file that I've inherited from a dev I loathe. There is a lot of dead code, and I find I've spent a lot of time refactoring functions that aren't even called.
Ideally, I just want something that can tie into the js engine and keep track of when and how many times functions are called.
In FF, I can get a list of the functions by walking the window object, and dynamically wrap them all in a method that would log the call to them, and then call the function as normal.
Unfortunately, in IE, I can't use this as I can't seem to find a way to get a list of all the functions that have been loaded. And I can't run this app in FF, as it's horribly browser specific. At last count there were 138 lines containing "new ActiveXObject(...)"
Help, either with a tool that can do this, or at the very least, a way to get a list of the functions that IE7 has loaded from the user script.
Thanks
-c
Try JSCoverage.
JSCoverage is a tool that measures
code coverage for JavaScript programs.
JSCoverage works by instrumenting the
JavaScript code used in web pages.
Code coverage statistics are collected
while the instrumented JavaScript code
is executed in a web browser.
The instrumentation can be done on-the-fly if you set the JSCoverage Server to run as an HTTP proxy and configure your browser to go through it.
One way to use it is:
Launch JSCoverage Server in proxy mode:
jscoverage-server --proxy --verbose
Configure your browser to you use localhost:8080 as the HTTP proxy.
Add the following bookmarklet, making sure the relative path to jscoverage is correct:
javascript:void(window.open('jscoverage/jscoverage.html'))
Run your tests.
Run the bookmarklet. It will popup a new window that shows you the coverage results.
There is a Firebug extension for JS Code Coverage...
FirebugCodeCoverage 0.1 (https://addons.mozilla.org/en-US/firefox/addon/4837)
Unfortunately, its not currently updated for the latest version of FF.