VSCode Version: 1.12.2
OS Version: Windows 10
Electron Version: 1.7
Steps to Reproduce:
I did an NPM update for electron, and a few other modules, and the Debug Launch of Electron stopped working. However, I can still manually start Electron from the command prompt, and it seems that the same command is what VSCODE is doing.
I.e. this works:
> d:\wwwroot\librarian2017\dashboard/node_modules/.bin/electron.cmd --debug-brk=24964 --nolazy main.js
But I get the message (below) when I run launch.json, and the blue status bar at the bottom of the VSCODE window turns orange for a second and then goes back to blue. No indication of what crashed. But nothing pops up.
Debugging with legacy protocol because a runtime executable is set.
d:\wwwroot\librarian2017\dashboard/node_modules/.bin/electron.cmd --debug-brk=24964 --nolazy main.js
Launch.json
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "DashBoard",
"program": "${workspaceRoot}/main.js",
"stopOnEntry": false,
"args": [],
"cwd": "${workspaceRoot}",
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd",
"env": {},
"sourceMaps": true
}
Probably a bug in VSCODE. I rolled electron back to 1.6.7 and it works again. I filed an issue on github.
Related
What am I doing?
I have a native iOS app with an integrated Flutter add-to-app module. In order to debug the dart code, I launched the native app in an iOS Simulator, then I ran flutter attach to attach the Flutter debugger to the native app.
Below is my launch.json file.
"version": "0.2.0",
"configurations": [
{
"name": "chope_app_flutter",
"request": "launch",
"type": "dart"
},
{
"name": "chope_app_flutter (iOS attach)",
"request": "attach",
"type": "dart"
},
],
}
What is the problem?
Sometimes, when I start debugging flutter attach, some errors occur.
There are multiple observatory ports available.
Rerun this command with one of the following passed in as the appId:
flutter attach --app-id com.example.id
flutter attach --app-id com.example.id (2)
I know it's ok to run this in the terminal, but I want to debug flutter code in VSCode.
Can someone help to resolve this issue?
Thanks!
I trying to build an electron with an exe installer on macOS with a MacBook Pro with an m1. I already tried different packages like electron-packager, electron-forge, but unfortunately, none of my tries worked. Did anyone has a solution to build an electron version with an exe on macOS.
My latest approach looked like, but when I start and after more then 30 minute it still do no finish.
yarn run electron-forge make --arch=x64 --platform=win32
The current code could be found here.
We using electron-builder for packaging electron app on Windows&MacOS(x86_x64/arm etc.), and you can try it.
add some config in package.json, like this:
"build": {
"appId": "com.electron.yourappid",
"productName": "your-product-name",
"asar": false,
"mac": {
"target": [
"pkg"
],
"entitlements": "entitlements.mac.plist"
},
"win": {
"target": [
{
"target": "zip",
"arch": [
"x64"
]
},
{
"target": "msi",
"arch": [
"x64"
]
}
]
}
},
"scripts": {
"dist": "electron-builder"
},
then run npm command like this:
# add package in your project
npm install --save-dev electron-builder
npm run dist # or 'npx electron-builder'
If you perfer using 'shelljs', create a file 'dist.js', and content:
const { exec, rm } = require('shelljs');
exec('electron-builder');
and then run node command
npm install --save-dev shelljs
node dist.js
More detail for config you can read offical doc of electron-builder.
I've looked into it and failed (building Apple Silicon, Apple Intel and Windows distributables from M1 Mac). I ended up setting up VMs that I use for building the distributables, and testing also.
electron-builder 23.0.3 and flag --universal work for me on Macbook M1 2021
This works for me. npx electron-builder --win --x64
I have been trying to debug C++ code via VScode on a remote docker container. While this is working for 2 of my other college's it isn't for me. We both use the same docker image. So I suspect it's something in my VScode, but what I do not know.
I get the following error when debugging the source code.
Unable to open 'malloc.c': Unable to read file 'vscode-remote://attached-container+7b22636f6e7461696e65724e616d65223a222f637070616e74227d/build/glibc-S9d2JN/glibc-2.27/malloc/malloc.c' (Error: Unable to resolve non-existing file 'vscode-remote://attached-container+7b22636f6e7461696e65724e616d65223a222f637070616e74227d/build/glibc-S9d2JN/glibc-2.27/malloc/malloc.c').
I can "fix" this by extracting glibc in /build/, but I would rather have it fix forever and not have the same issue with another docker container (possible). Glibc is installed in the Docker container at /usr/src/glibc. I found it by running find / -iname glibc.
To run the application from VScode on the remote docker container, I use this launch.json file:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch Program",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/src/application",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/build/src",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
Not sure if this information is necessary but it cant do harm.
host: Windows 10
docker container: ubuntu 18:04
visual studio code version: 1.55.0
Hopefully, this is enough information to resolve the issue I'm facing.
Once I had set launch.json and I ran gdb and debugged in my code successfully until something happened and all breakpoint became "gray" with the such message:
"Module containing this breakpoint has not yet loaded or the breakpoint address could not be obtained."
However, debugger attaches to running program and I even can make steps from main, but still breakpoint are not hit... This is C++ project that is built with cmake with gcc with -DCMAKE_BUILD_TYPE=DEBUG flag.
launch.json is this:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "./MyProject/project",
"args": [],
"stopAtEntry": false,
"cwd": "/home/AA/workspace",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"miDebuggerServerAddress": "/*Cannot write here, but it's fine*/",
"sourceFileMap": {/*Cannot write here, but it*/}
},
]
}
How do I fix this problem?
I was looking for an answer in other resources and the most solutions say that you should -g option if you compiler a project with gcc. It wasn't my case because I use cmake but I had one detail that I debugged code that was run in docker.
When you work with files in VS code from your user and docker runs project from another user, you should add the option "sourceFileMap": {} in launch.json:
"sourceFileMap": {
"/home/user/project/file.hpp" : "/home/YourNameBeyondDocker/project/file.hpp",
...
I added wrong path in this option. When I took it out, my debugger finally started hitting breakpoints!
I have an Electron app that I was able to debug in Visual Studio Code. After I upgraded to version 0.10.8 it will no longer run.
I am getting the error message below in my launch.json file:
Relative paths will no longer be automatically converted to absolute ones. Consider using ${workspaceRoot} as a prefix.
Absolute path to the runtime executable to be used. Default is the runtime executable on the PATH.
Here is my launch.json file:
{
"version": "0.2.0",
"configurations": [
{
"name": "My First Electron App",
"type": "node",
"request": "launch",
"program": "$(workspaceRoot}/app/main.js", //ERROR
"stopOnEntry": false,
"args": [],
"cwd": "$(workspaceRoot}",
"runtimeExecutable": "$(workspaceRoot}/node_modules/electron-prebuilt/dist/electron.app/Contents/MacOS/Electron", //ERROR
"runtimeArgs": [
"--nolazy"
],
"env": {
"NODE_ENV": "development"
},
"externalConsole": false,
"sourceMaps": false,
"outDir": null
},
{
"name": "Attach",
"type": "node",
"request": "attach",
"port": 5858
}
]
}
I am getting the green squiggly line mentioned for the two lines with //ERROR at the end.
I saw this article, but honestly was familiar with VS Code enough to understand how this should be implemented: https://code.visualstudio.com/Docs/editor/tasks#_variable-substitution
UPDATE
I replaced the value for "cwd" with "${workspaceRoot}" as recommended by Isidor. The green squiggly line went away.
I updated the error message that I am still seeing on the other two lines.
When I hit F5 I get this error message:
request 'launch': runtime executable '/private/var/git/electron-vs-code/$(workspaceRoot}/node_modules/electron-prebuilt/dist/electron.app/Contents/MacOS/Electron' does not exist
There is a typo in your json. Change the parenthesis after the $ in $(workspaceRoot} to a curly brace. This should at least fix the warning.
Even though you are getting the relative path warning VSCode still automatically converts relative to absolute paths in 0.10.8. To get rid of the warnings for "cwd", instead of "." please put "${workspaceRoot}".
What happens when you run try to debug your electron app, do you see some other error, since the relative to absolute can not be the true cause of this. If you command palette / open developper tools -> do you see some error in the console?