If I start a Node.js process with the --inspect flag then I get a URL in the console for me to debug the application using Chrome dev tools.
eg
Debugger listening on
ws://127.0.0.1:9229/fa66d6b2-2011-4e4f-bafc-fc9a300a36d5
If I make a change to my application, I need to restart the application process, and this results in a completely new debug URL.
This is inconvenient because I already have Chrome dev tools pointing at the old URL.
How can I have the process automatically restart on application source code changes and maintain the same dev tools debugging session to avoid the need to manually reconfigure dev tools for every change?
You can use the Node Inspector Manager plugin. It has the ability to listen to the inspector and automatically open in a new tab. This is a big part of my development workflow.
Related
Is there a way to open devtools on production builds of Electron that were packaged and distributed to you?
For instance, I'd like to poke around Slack's app. I know that it's built in Electron, and I'd like to open devtools to see how some parts of it are built.
On macOS I've tried:
ELECTRON_ENV=development /Applications/Slack.app/Contents/MacOS/Slack --debug --auto-open-devtools-for-tabs
as well as the usual key combination of Cmd+Option+I and checking for debug menus/views.
None of these seem to make a difference.
Note that there are already a few solutions that recommend you do it programmatically by injecting:
remote.BrowserWindow.getFocusedWindow().webContents.openDevTools()
However I can't do that because I don't have access to the source code or the original build process. Is there a way to trigger devtools externally?
The most promising way I've seen so far is remote-debugging-port but I'm not sure it works with production builds.
The way to do this without third-party code is indeed using the --remote-debugging-port flag.
Using Signal as an example, take the following steps:
start the application from the CLI
signal-desktop --remote-debugging-port
Open the debugging URL in a Google Chrome browser (in this case http://localhost:39733/), this will open a page with the app name on it .
Click the to open a screen were you can click around to use the app and see output in the devtools
Alternatively, you can open chrome://inspect/#devices in the Google Chrome browser and click "inspect" (underneath the app name) to open the same window
Once a node.js program has run to completion in the context of an --inspect session (i.e. via the Chrome dev tools debugger) is it possible to re-start it without having to re-issue the --inspect command from the command-line?
The issue with re-issuing an --inspect command is that it generates a different chrome url every time and one has to then copy-paste this into Chrome each time. Ideally I want to be able to push F5 to re-start the chrome debug session.
So two issues:
I cannot restart the debug session without killing the current (i.e. no way to just refresh).
I have to copy paste the url into chrome each time I start a new session. (not as bad as issue 1.)
Here's a couple of options for you, though neither will provide you with a simple F5 refresh, both are significantly better than copy/pasting the new URL generated by the --inspect flag.
The most optimal solution is installing this extension for Chrome or Opera: https://chrome.google.com/webstore/detail/nim-node-inspector-manage/gnhhdgbaldcilmgcpfddgdbkhjohddkj
This will manage the node inspector for you. Just click the resulting toolbar icon and select "Auto" from the toggle switch. Your browser will then open the Chrome DevTools in inspection mode whenever your node server generates an inspection URL.
If you want to go the low-tech (and more manual) route, or don't want to install a Chrome extension, just open your Chrome to "chrome://inspect", wait a moment, and you'll get a list under Remote Target that will include your Node server. Just click the "inspect" link there, and the DevTools will open with the current URL. The downside of this method is you'll need to reclick that "inspect" link every time your server restarts. It avoids copy/pasting URLs, but still involves manual labor.
It's also significant to note that if you simply update the url of your inspector with the new ID, it will also work.
When you restart node, you'll get something like this:
Debugger listening on ws://127.0.0.1:9222/72c791b7-178f-47e8-93b1-d1be4d5ffe1e
The bit after the port/ is what you want. Replace that code in your inspector's url and it will connect to the latest session.
I cannot figure out how to debug javascript, using PyCharm, in a Django template.
When I attempt to debug a template -- by using the context menu item Debug while in the template -- the debugger launches, chromium launches, and I see the following error message in the PyCharm debugger console:
GET http://localhost:8000/login net::ERR_CONNECTION_REFUSED
Needless to say nothing shows up in the chromium window.
I've seen hints that I'm supposed to "open the generated file" from within the PyCharm debugger scripts tab. But since chromium isn't loading anything there's nothing to open.
I have the JetBrains chromium debugger installed and, so far as I can tell, running.
What's the procedure for debugging javascript in a Django template from within PyCharm?
Set up a debug configuration for Javascript (not Remote Firefox/Remote Chrome as the documentation might lead you to). Set the URL to the entrypoint of your application that renders the template and run this config. It should launch a browser and stop at any breakpoints you set in your javascript in pycharm.
Why not using a browser tool like firebug in browser or google chome debugging tools (depending on the browser you use), If your code is client side, since I assume that the server side part of the application is written in python scripts it's the easiest solution.
I have also used JSDT in eclipse but it was not as convenient.
For the error you posted I think it's server-side / networks error, check your views.py or an example from the django tutorial to see if it is exposed in WSGI (django default web server ).
I am working on a small web api project in Visual Studio 2013 Ultimate. Windows 2013. Internet Explorer 9. When I run (debug) from VS using the internal web server (I guess that is IIS Express, now), I am finding that the changes I am making (and saving) to a javascript page are being ignored. Placing a breakpoint in the javascript shows the older code without my changes.
CTRL+F5 does not force the application to use the currently updated page. Checking the page in, then checking it back out often works. Is there some setting or trick that will help me out here?
Clearing the cache history seemed a bit excessive and I don't want to do that all the time.
The following solution worked me in Internet Explorer:
First enable script debugging:
Tools menu -> select Internet Options
On advance tab uncheck "Disable script debugging (Internet Explorer)"
Then make sure you get the newest page:
From the Tools menu choose Internet Options.
On the General tab, under Browsing history, click Settings.
Under "Check for newer versions of stored pages" make sure "Every time I visit the webpage" is selected.
Click the OK button.
If somebody has this problem and ctrl+F5, clearing browser's cache, restarting debugging, changing browser, changing web.config and rebuilding project don't help, then there is one last thing that works (at least for me): restart Visual Studio.
Also changing debugging port on local IIS Express helps but this is far more painful if working in a team or using Azure Active Directory etc.
Only solution that worked for me was changing the javascript file name and updating the bundle configuration to point at the new file. I tried everything else from restarting my pc, deleting bin/obj/cache/etc, CTRL F5, restart IIS, and so on.
If I'm correct you should build (ctrl+shift+b) your project before debugging. This web server runs in the background on a port of choosing whenever you start in debug mode. You can close the task(s) (process bar next to your clock) if you need a new session or press F5 in VS.
You can avoid using the built in web server if you have IIS (Express) or something similar.
Go to RUN and type iis depending on your OS it's already installed. Otherwise try to install it in Control Panel > Programs or Features > Turn windows features on or off
add a website (site name, path, hostname)
add to your host file 127.0.0.1 hostname (c:\windows\system32\drivers\etc\hosts)
To debug your project in Visual Studio:
open your website on your hostname in your favourite browser
click on DEBUG
click on ATTACH TO PROCESS
find w3wp.exe
hit ctrl+f5 in your browser to start debugging server code
Depending on how your solution/project is setup, you can publish your project files directly to IIS if you choose to publish to File System. Right mouse click on your project and choose publish. Set it up from there.
If your Visual Studio is up-to-date you can publish single files with alt+$+p.
Hope it helps.
Locate the code section where the JavaScript file is loaded to the page and add a parameter string to the end for testing. For example:
Change src="../Resources/js/MyScriptFile.js"
To src="../Resources/js/MyScriptFile.js?v=23"
Every time you update your JavaScript file, you change the version number. This will force the browser to load your new version of JavaScript file. After you finished testing, You can remove the string "?v=23". The bonus, if you leave it there, the end user will not be required to refresh his/her browser cache after you deployed your code to production.
I keep getting this problem very often. Normally what I do is first get into the drive where the OS is installed (In my case C:), and delete all the application.dll and application.pdb (it is stored in Windows\Microsoft.net\Framework\vx.x.xxxxx\Temporary ASP.NET Files). Delete application.dll and application.pdb in the users\xxx. Get into the application directory and again delete application.dll and application.pdb. Clear the browser cache. Restart the system (cold restart). Build the application. Most of time found to be working.
Note: I use DOS prompt for deleting since I'm quite used to it. But the user should have admin privileges. It's not a perfect solution but it works.
What worked for me was
Shutdown Visual Studio 2013 update 2 (I have win 8.1 all 64 bit)
Delete clear out "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files"
Cleaned and Rebuilt solution
Restart IIS Express. If using IIS just re start app and pool.
Run in VS 2013 Debug (F5) it still loads the old file under Script Documents > Windows Internet Explorer > Page_Name.aspx
Then F12 Developer tools clear Browser Cache (IE), I have the same issue in Chrome
F5 in browser reload the page finally loads the changed JS script file with my debugger; entry and breakpoints set
So i had the same problem and i could avoid this by canceling the .ASP.NET-Server
.ASP.NET-Server from Visual Studio for debugging
from Visual Studio and restarting the debugging. Hope this helps someone.
I restarted Visual Studio and rebuilt the project, but the problem persisted for me -- the debugger continued to run an old copy of the .js file. The solution for me was to simply reboot the machine. (When all else fails...)
For reference, I'm currently using Visual Studio 2015.
Typically to debug an app, I will hit F5 to start debugging it. However I want this app not already running and it activated due to ActivationKind = search. If I hit F5, then app will get activated with ActivationKind = launched. Any ideas how to do it?
If you go to Project Properties->Debug there is an option call "Do not launch, but debug my code when it starts". With this enabled, run your application (F5 or however you prefer) and then when you click on the tile for your application or activate it some other way, then it will debug with your currently running debug session.
In the Debug properties for your Windows Store project, select the option Do not launch, but debug my code when it starts, then initiate a debug session.